Network Service Header (NSH)
draft-ietf-sfc-nsh-28

[Ballot comment]
Thank you for adding the new text in S 8.2.1. I continue to be concerned about the challenge of securing this kind of protocol, but that's a bigger problem we as the IETF need to resolve.

[Ballot comment]
Thank you very much for the new security considerations section.  The added text to fully explain the current state as well as the pitfalls of the solution is quite helpful.  The work put into understanding the issues (both from the security side as well as from the architecture/solution limitations) and documenting them was substantial and I hope it helps improve future work.  I do understand that the WG has hurdles to provide integrity protection, but also don't see immediate solutions.  I do appreciate the text that acknowledges this problem and that offers some mitigating options.  While I appreciate the changes, I'd like to see better options going forward in routing area protocols and as such, I will abstain since the security property of integrity is not addressed in this solution.

[Ballot comment]
I'm clearing my discuss now, however, I don't think all of my comments have been adequately addressed. However, some points could be clarified such that these open points do not warrant to hold a discuss anymore.

--------------------
Old discuss text:
--------------------
I have a couple of comments on the design. I know, as always in IESG review state, it's probably too late to make any changes to the actual header format, therefore most of my comments are actually in the comment section below. I still decided to note them so at least people can consider these points. However, there are a few things that I need clarification for before publication, which I note in this section:

1) Sec 2.2
"SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
  OAM procedures SHOULD discard packets with O bit set, but MAY support
  a configurable parameter to enable forwarding received SFC OAM
  packets unmodified to the next element in the chain.  Forwarding OAM
  packets unmodified by SFC elements that do not support SFC OAM
  procedures may be acceptable for a subset of OAM functions, but can
  result in unexpected outcomes for others; thus, it is recommended to
  analyze the impact of forwarding an OAM packet for all OAM functions
  prior to enabling this behavior.  The configurable parameter MUST be
  disabled by default."
This part is really unclear to me and I believe needs to be further specified. Where should this configurable parameter be? In the Context header? Why don't you just use one of the unassigned bit to indicate if an unknown (OAM) packet should be forwarded or not?
Moreover, I also disagree with this text. If there is a bit/a way to indicate if a not supported OAM packet should be forwarded or not, it should just be defined like this, while any considerations if that bit should be set or not depend on the OAM function itself and do not need to be discussed here.
Finally, it is not well explained what an OAM packet is at all. Is that a 'fake' packet that is generated by the operator to actively test the (potentially newly configured) SFP? If so, why does a SF need to know if a packet is an OAM packet or not? Usually it's a bad idea to use different kind of traffic for testing compared to what will be used in operations. Please provide more explanation here!

2) section 2.4
"An SFC-aware SF MUST receive the data semantics first in order to
  process the data placed in the mandatory context field.  The data
  semantics include both the allocation schema and the meaning of the
  included data.  How an SFC-aware SF gets the data semantics is
  outside the scope of this specification."
This is really confusing to me. I think this is what you need an actually data semantics aka type field for in the base header. Or is there an actual reason to not put this information directly in the base header where it is need but instead assuming some magical way this information may take to reach the node? If the assumption is that the SF is configured to know based of the SFI what the content of the context header has to be, you a) need to say that in the draft, and b) that's really error-prone because it's really hard to tell if the conext header actually holds the information that you need or just random crap (of course depending of the expected data type of this information). In short, I think you really need a type field somewhere here. In any case, you really need to explain this more!
Also, the text further says:
"An SF or SFC Proxy that does not know the format or semantics of the
  Context Header for an NSH with MD Type 1 MUST discard any packet with
  such an NSH..."
How does the SFC proxy know that it knows the format or not if there is no type field or identifier that indicates what the format should be?

Also, a related question from me: why is the context header present in all types of NSH if there is no use for it defined in this document yet? Why is there no fixed length NSH without a context header then?

3) Section 2.5.1:
"If multiple instances of the same metadata are included in an NSH
  packet, but the definition of that context header does not allow for
  it, the SFC-aware SF MUST process the first instance and ignore
  subsequent instances."
This seems error prone to me. If the same metadata appears multiple where it should not, that seems clearly like an error case for me. Just using the first one and proceed normally might not be the right thing to do. In any case I think such an occasion should at least be logged. If the multiple instances are just a copy of each other and carry the same information, it's probably okay to use that information and proceed. If the different instances carry different information, it maybe a bit dangerous to just use the first one and ignore others silently. In this case I would rather recommend to drop the packet...

4) In line with the second comment from the tsv-art review (thanks Wes!), I don't really understand why this documents says (sec 6) that there can be multiple next hops for the same SFP or SFs can be traversed in a different order. May understanding (from a quick look at RFC7665) would be that, if those things are needed e.g. for load balancing, then one should define different SFPs and the Classifier must have the knowledge that two SFP are equivalent and select them respectively. The reason why I'm really concerned about this is that usually a number of packets below to a flow and all packets belonging to the same flow just ideally take the same route. But usually only the Classifier has a notion of what a flow is and respectively will assign the SFI to the packets belonging to the same flow. If now any SF on the path can more or less randomly decided to forward packet belong to the same flow to one or another next nodes, I would assume that this is not only a problem for the flow, e.g. reordering, but also for SF itself in many cases.

------------------------
Old comment text:
------------------------

Further considerations:

1) I don't really see why a TTL in the base header is needed. I mostly understand why there is the Service Index in service header, also I think there should be better mean to validate that you SFP is correct and I ideally you should really not need this. However, loop prevention can be provided by both mechanism and moreover there is probably also often a TTL in the encapsulation protocol and loop prevention should really be a function of that forwarding protocol and not the NSH.

2) I don't see why you need the type field in the base header. This is fully redundant because because all you need is the length field. If the length is 0x2 it is what you have defined as type 1 if the length field is larger it is type 2. I also don't see the need for any other types in future because you also have the version field; if you need anything else you should go or probably have to go for a new version. Note that the general probably with unnecessary redundancy is that is add complexity. If you keep this redundancy you have to separately handle and implement the case(s) where the type is 1 but the length is larger than expected. If at all you could probably just use one bit to indicate that the length field is present and if not the length is 0x2. However, saving bits does not really seem to be a concern for you, so that might not actually be an advantage.

3) sec 2.5.1
"Unassigned bit: One unassigned bit is available for future use.  This
  bit MUST NOT be set, and MUST be ignored on receipt."
Is there an actual reason to have an unassigned bit here? Because I would assume that the type already provided enough flexibility for way to extend the metadata format in any way needed.

4) Also section 2.5.1:
"  Length: Indicates the length of the variable metadata, in bytes.  In
  case the metadata length is not an integer number of 4-byte words,
  the sender MUST add pad bytes immediately following the last metadata
  byte to extend the metadata to an integer number of 4-byte words.
  The receiver MUST round up the length field to the nearest 4-byte
  word boundary, to locate and process the next field in the packet."
Your definition of the length field might be more error-prone than needed. It would probably be easier to simply define the length as 4-byte words, and the  type of course defines the content of the metadata field and as such can simply define which part of the total metadata field holds certain data of a certain type and with part is padding.

5) And finally I have to say it is unclear to me why the SFI and SI field are described as a separate header. Given they have to be present in all SFH, I would consider them as two fields of the base header. But it is after all really just an editorial issue. However, all this together with my previous comments makes the protocol spec actually much more complicated than it needs to be...

6) I also have to agree to the last comment of the tsv-art review: I think it would have been nicer to not only described the NSH but also define mappings to a set of possible encapsulations because I would assume that for each encapsulation there are a couple specific considerations that need to be made to make things work successfully. I don't think that all encapsulations can be captured by general consideration and I cannot make up my mind to go through all cases in my head to figure out if there are things that needs to be noted.

[Ballot comment]
I'm clearing my discuss now, however, I don't think all of m comments have been adequately addressed. However, some points could be clarified such that these open points do not warrant to hold a discuss anymore.

--------------------
Old discuss text:
--------------------
I have a couple of comments on the design. I know, as always in IESG review state, it's probably too late to make any changes to the actual header format, therefore most of my comments are actually in the comment section below. I still decided to note them so at least people can consider these points. However, there are a few things that I need clarification for before publication, which I note in this section:

1) Sec 2.2
"SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
  OAM procedures SHOULD discard packets with O bit set, but MAY support
  a configurable parameter to enable forwarding received SFC OAM
  packets unmodified to the next element in the chain.  Forwarding OAM
  packets unmodified by SFC elements that do not support SFC OAM
  procedures may be acceptable for a subset of OAM functions, but can
  result in unexpected outcomes for others; thus, it is recommended to
  analyze the impact of forwarding an OAM packet for all OAM functions
  prior to enabling this behavior.  The configurable parameter MUST be
  disabled by default."
This part is really unclear to me and I believe needs to be further specified. Where should this configurable parameter be? In the Context header? Why don't you just use one of the unassigned bit to indicate if an unknown (OAM) packet should be forwarded or not?
Moreover, I also disagree with this text. If there is a bit/a way to indicate if a not supported OAM packet should be forwarded or not, it should just be defined like this, while any considerations if that bit should be set or not depend on the OAM function itself and do not need to be discussed here.
Finally, it is not well explained what an OAM packet is at all. Is that a 'fake' packet that is generated by the operator to actively test the (potentially newly configured) SFP? If so, why does a SF need to know if a packet is an OAM packet or not? Usually it's a bad idea to use different kind of traffic for testing compared to what will be used in operations. Please provide more explanation here!

2) section 2.4
"An SFC-aware SF MUST receive the data semantics first in order to
  process the data placed in the mandatory context field.  The data
  semantics include both the allocation schema and the meaning of the
  included data.  How an SFC-aware SF gets the data semantics is
  outside the scope of this specification."
This is really confusing to me. I think this is what you need an actually data semantics aka type field for in the base header. Or is there an actual reason to not put this information directly in the base header where it is need but instead assuming some magical way this information may take to reach the node? If the assumption is that the SF is configured to know based of the SFI what the content of the context header has to be, you a) need to say that in the draft, and b) that's really error-prone because it's really hard to tell if the conext header actually holds the information that you need or just random crap (of course depending of the expected data type of this information). In short, I think you really need a type field somewhere here. In any case, you really need to explain this more!
Also, the text further says:
"An SF or SFC Proxy that does not know the format or semantics of the
  Context Header for an NSH with MD Type 1 MUST discard any packet with
  such an NSH..."
How does the SFC proxy know that it knows the format or not if there is no type field or identifier that indicates what the format should be?

Also, a related question from me: why is the context header present in all types of NSH if there is no use for it defined in this document yet? Why is there no fixed length NSH without a context header then?

3) Section 2.5.1:
"If multiple instances of the same metadata are included in an NSH
  packet, but the definition of that context header does not allow for
  it, the SFC-aware SF MUST process the first instance and ignore
  subsequent instances."
This seems error prone to me. If the same metadata appears multiple where it should not, that seems clearly like an error case for me. Just using the first one and proceed normally might not be the right thing to do. In any case I think such an occasion should at least be logged. If the multiple instances are just a copy of each other and carry the same information, it's probably okay to use that information and proceed. If the different instances carry different information, it maybe a bit dangerous to just use the first one and ignore others silently. In this case I would rather recommend to drop the packet...

4) In line with the second comment from the tsv-art review (thanks Wes!), I don't really understand why this documents says (sec 6) that there can be multiple next hops for the same SFP or SFs can be traversed in a different order. May understanding (from a quick look at RFC7665) would be that, if those things are needed e.g. for load balancing, then one should define different SFPs and the Classifier must have the knowledge that two SFP are equivalent and select them respectively. The reason why I'm really concerned about this is that usually a number of packets below to a flow and all packets belonging to the same flow just ideally take the same route. But usually only the Classifier has a notion of what a flow is and respectively will assign the SFI to the packets belonging to the same flow. If now any SF on the path can more or less randomly decided to forward packet belong to the same flow to one or another next nodes, I would assume that this is not only a problem for the flow, e.g. reordering, but also for SF itself in many cases.

------------------------
Old comment text:
------------------------

Further considerations:

1) I don't really see why a TTL in the base header is needed. I mostly understand why there is the Service Index in service header, also I think there should be better mean to validate that you SFP is correct and I ideally you should really not need this. However, loop prevention can be provided by both mechanism and moreover there is probably also often a TTL in the encapsulation protocol and loop prevention should really be a function of that forwarding protocol and not the NSH.

2) I don't see why you need the type field in the base header. This is fully redundant because because all you need is the length field. If the length is 0x2 it is what you have defined as type 1 if the length field is larger it is type 2. I also don't see the need for any other types in future because you also have the version field; if you need anything else you should go or probably have to go for a new version. Note that the general probably with unnecessary redundancy is that is add complexity. If you keep this redundancy you have to separately handle and implement the case(s) where the type is 1 but the length is larger than expected. If at all you could probably just use one bit to indicate that the length field is present and if not the length is 0x2. However, saving bits does not really seem to be a concern for you, so that might not actually be an advantage.

3) sec 2.5.1
"Unassigned bit: One unassigned bit is available for future use.  This
  bit MUST NOT be set, and MUST be ignored on receipt."
Is there an actual reason to have an unassigned bit here? Because I would assume that the type already provided enough flexibility for way to extend the metadata format in any way needed.

4) Also section 2.5.1:
"  Length: Indicates the length of the variable metadata, in bytes.  In
  case the metadata length is not an integer number of 4-byte words,
  the sender MUST add pad bytes immediately following the last metadata
  byte to extend the metadata to an integer number of 4-byte words.
  The receiver MUST round up the length field to the nearest 4-byte
  word boundary, to locate and process the next field in the packet."
Your definition of the length field might be more error-prone than needed. It would probably be easier to simply define the length as 4-byte words, and the  type of course defines the content of the metadata field and as such can simply define which part of the total metadata field holds certain data of a certain type and with part is padding.

5) And finally I have to say it is unclear to me why the SFI and SI field are described as a separate header. Given they have to be present in all SFH, I would consider them as two fields of the base header. But it is after all really just an editorial issue. However, all this together with my previous comments makes the protocol spec actually much more complicated than it needs to be...

6) I also have to agree to the last comment of the tsv-art review: I think it would have been nicer to not only described the NSH but also define mappings to a set of possible encapsulations because I would assume that for each encapsulation there are a couple specific considerations that need to be made to make things work successfully. I don't think that all encapsulations can be captured by general consideration and I cannot make up my mind to go through all cases in my head to figure out if there are things that needs to be noted.

[Ballot comment]
- Section 2.5.1., you might want to mention that no metadata are specified at this point in time.
Indeed, "New IETF Assigned Optional Variable Length Metadata Type Registry is specified in this doc., but empty

- Section 2.3
OPS question: SPI must be unique per admin domain? Otherwise, you're looking for trouble, right?
This would be typically addressed in an "Operational Considerations" section.
Where is my "Operational Considerations" section...?

- Section 2.4
Fixed length metadata.

  This specification does not make any assumptions about the content of
  the 16 byte Context Header that must be present when the MD Type
  field is set to 1, and does not describe the structure or meaning of
  the included metadata.

  An SFC-aware SF MUST receive the data semantics first in order to
  process the data placed in the mandatory context field.  The data
  semantics include both the allocation schema and the meaning of the
  included data.

I understand that the order of the metadata in the Fixed Length Context Header is important, right? Should it be mentioned?
I understand that the fixed length metadata are specific per service, and that's the reason why there is no IANA for fixed length.
Should this be mentioned?


- if you publish a new version, change the order of these two paragraphs:

  Unassigned bits: All other flag fields, marked U, are unassigned and
  available for future use, see Section 11.2.1.  Unassigned bits MUST
  be set to zero upon origination, and MUST be ignored and preserved
  unmodified by other NSH supporting elements.  At reception, all
  elements MUST NOT modify their actions based on these unknown bits.

  Length: The total length, in 4-byte words, of the NSH including the
  Base Header, the Service Path Header, the Fixed Length Context Header
  or Variable Length Context Header(s).  The length MUST be 0x6 for MD
  Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to
  0x2.  The length of the NSH header MUST be an integer multiple of 4
  bytes, thus variable length metadata is always padded out to a
  multiple of 4 bytes.


Lacking some time before the telechat, but not worth deferring (there are enough DISCUSS'). FYI, I arrived at section 5.

[Ballot comment]
- Section 2.5.1., you might want to mention that no metadata are specified at this point in time.
Indeed, "New IETF Assigned Optional Variable Length Metadata Type Registry is specified in this doc., but empty

- Section 2.3
OPS question: SPI must be unique per admin domain? Otherwise, you're looking for trouble, right?
This would be typically addressed in an "Operational Considerations" section.
Where is my "Operational Considerations" section...?

- Section 2.4
Fixed length metadata.

  This specification does not make any assumptions about the content of
  the 16 byte Context Header that must be present when the MD Type
  field is set to 1, and does not describe the structure or meaning of
  the included metadata.

  An SFC-aware SF MUST receive the data semantics first in order to
  process the data placed in the mandatory context field.  The data
  semantics include both the allocation schema and the meaning of the
  included data.

I understand that the order of the metadata in the Fixed Length Context Header is important, right? Should it be mentioned?
I understand that the fixed length metadata are specific per service, and that's the reason why there is no IANA for fixed length.
Should this be mentioned?


- if you publish a new version, change the order of these two paragraphs:

  Unassigned bits: All other flag fields, marked U, are unassigned and
  available for future use, see Section 11.2.1.  Unassigned bits MUST
  be set to zero upon origination, and MUST be ignored and preserved
  unmodified by other NSH supporting elements.  At reception, all
  elements MUST NOT modify their actions based on these unknown bits.

  Length: The total length, in 4-byte words, of the NSH including the
  Base Header, the Service Path Header, the Fixed Length Context Header
  or Variable Length Context Header(s).  The length MUST be 0x6 for MD
  Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to
  0x2.  The length of the NSH header MUST be an integer multiple of 4
  bytes, thus variable length metadata is always padded out to a
  multiple of 4 bytes.


Lacking some time before the telechat, but not worth deferring (there are enough DISCUSS'). FYI, I arrived at section

[Ballot discuss]
* Section 5

I think the fragmentation part is underspecified. Take an example where IPv6 is used as the transport encapsulation. If the packet needs to be fragmented, will the NSH header be duplicated into each fragment? If so, this is new behavior for IP that will treat this like any other payload. If not how will the subsequent fragments be treated on the service path?

[Ballot discuss]
* Section 5

I think the fragmentation part is underspecified. Take an example where IPv6 is used as the transport encapsulation. If the packet needs to be fragmented, will the NSH header be duplicated into each fragment? If so, this is new behavior for IP that will treat this like any other payload.

[Ballot comment]
* Section 1.2.

The definition of metadata seems to point to RFC7665 but the definition that follows does not match the definition from RFC7665.

* Section 2.2

What does a "Next Protocol" with the value of 0x4 (NSH) mean? Does the NSH allow nesting. How will such system work?

* Section 3

"The O bit, as well as unassigned flags, MUST be copied transparently from the old NSH to a new NSH."

If there is reclassification, why is there an assumption that an OAM packet cannot be reclassified into a non OAM packet since a new NSH header is being inserted?

* Section 8.1.
  Not sure what the reference to BCP38 means here. Is it for checking the source addresses the inner header that is getting encapsulated inside the NSH header? Or is it for the transport encapsulation header. Either way it is not clear what this entails. Please clarify.

* Section 11.1

This section mentions that ethertype 0x894F has been allocated for NSH. Are there any other transport encapsulations planned? If not, I would recommend tightening the text around the transport encapsulations until other encapsulations are more well defined. e.g. How does the UDP transport encapsulation referred in the example work?

[Ballot discuss]
I concur with Kathleen's DISCUSS. To state my view of things:

1. The assumption that the datacenter is a secure environment is not a
reasonable one. As Kathleen and Adam both observer, datacenter
breaches are common and that is why people are moving towards
encryption inside the data center. I see that this draft has text
claiming that this is only to be deployed in safe environments, but we
know that technologies like this get deployed outside the locations
for which we claim they are to be deployed, and there's nothing here
to stop that. Moreover, the whole trend towards cloud computing pushes
us away from designs in which you can safely talk about single secure
zones.

2. The text in S 8.1 about how you might want to use some kind of
transport security does not seem sufficient. As above, we know that if
we don't specify something, people will deploy this technology in
insecure settings without any kind of security.

I concur with Kathleen's point that this document should provide
built-in security mechanisms rather than just punting to the
under-layer. Given that as S 1 makes clear, all these SFs are part of
the same administrative domain, this seems like a comparatively less
challenging setting. If there is some reason why that's infeasible,
that needs to be explained.

[Ballot comment]
Line 143
                    |    Original Packet / Frame  |
                    +------------------------------+
Nit: I would have expected this stack to go the other way, with TE on the bottom.


Line 165
  overlay domain using virtual connections and tunnels.  A corollary is
  that a network administrative domain has a well defined perimeter.
This is not a reasonable assumption in modern datacenter environments, especially if you have virtualized services.


Line 372
  1 prior to NSH forwarding lookup.  Decrementing by 1 from an incoming
  value of 0 shall result in a TTL value of 63.  The packet MUST NOT be
  forwarded if TTL is, after decrement, 0.
I am having trouble following this, Is the point that I can emit a packet with TTL 0, which is effectively TTL 64?


Line 375
  This TTL field is the primary loop prevention This TTL mechanism
  represents a robust complement to the Service Index, as the TTL is
Nit: "prevention mechanism. This"?


Line 379
  better, although not perfect, interoperation with pre-standard
  implementations that do not support this TTL field.
This point would be clearer if it were made before the rule about decrement.


Line 403
  0x0 - This is a reserved value.  Implementations SHOULD silently
  discard packets with MD Type 0x0.
Why is this a SHOULD and not a MUST? That seems like it will create potential interop problems.


Line 651
      encapsulated packet.  It is therefore the last node operating on
      the service header.
Can you also nest NSHs?

[Ballot comment]
Substantive:

- General: This is a mechanism to add metadata to user flows. There is very little discussion about how that metadata may relate to the application layer payloads. It's likely that some of those payloads will be encrypted by the user in an attempt to control what information is shared with middleboxes. I'd like to see some discussion about how this relates to the guidance in RFC 8165.  (Note: I am on the fence about whether this should be a DISCUSS. But since "on the fence" is probably insufficient grounds for a DISCUSS, I'm leaving it as a comment.)

- General: I support Kathleen's DISCUSS points concerning integrity protection. The document leaves that up to the transporting protocol. I think it's reasonable to recommend that that protocol at least default to providing integrity protection unless there's a good reason not to.

-2.2, "version": How is the version field to be used by consumers? That is, what should a recipient do if the field contains a version number it doesn't support/recognize?

-2.2, MD type 0x0: "Implementations SHOULD silently
  discard packets with MD Type 0x0."
Why not MUST?

-- MD type 0xF: "Implementations not explicitly configured to be part of
  an experiment SHOULD silently discard packets with MD Type 0xF."
Why not MUST?

-2.2, Next Protocol Values:
Why are there 2 experimental values? (as opposed to 1, or, well, 3).

-2.3, last paragraph (and several other places):
This draft seems to take a position that a failed SFP means the service level flow fails. Are there no use cases where delivery of the service flow is critical and should happen even if the chain of middleboxes fails?

-2.4, paragraph starting with "An SFC-aware SF MUST receive the data semantics..."
I'm not sure what the intent of this paragraph is. Is that MUST really a statement of fact? Or is there really and expectation of an out-of-band delivery of some semantic definition?

-3, list item 1: "A service classifier MUST insert an NSH at the start of an SFP."
What if an initial classifier receives a packet that already has an NSH? Can multiple NSHs be stacked?

-7.1, last paragraph: "Depending on the information carried in the metadata, data privacy
  considerations may need to be considered. "
"may need to be considered" is weak sauce. Data privacy always needs to be considered, even if the _output_ of that consideration is that there is nothing sensitive being carried. Please consider dropping the "may".

Also, this seems like an odd place to bury a privacy discussion. Please consider moving this to a "Privacy Considerations" section.

-8, first paragraph:
It seems like insider attacks are worth at least a mention when discussing a single operator environment as a mitigator against attacks.

-8.1, 2nd paragraph:
This doesn't seem like a single operator scenario, in the sense that part of the flow crosses a network that is not controlled by that operator.

-8.3, 4th paragraph: Please elaborate on what is meant by "obfuscating" subscriber identifying information (as opposed to "encrypting" or "leaving it out in the first place".)

Editorial:

-2.2, "O bit", last paragraph: "The configurable parameter MUST be
  disabled by default."
Does "disabled" mean "unset"  (or "set to zero")?

-2.2, "unassigned bits": "At reception, all
  elements MUST NOT modify their actions based on these unknown bits."
Isn't that MUST NOT just a restatement of the "MUST ignore" from the previous sentence? There's no problem with reinforcing a point, but there shouldn't be multiple instances of the same 2119 requirement. Also, would logging a warning violate the "MUST NOT modify their actions/MUST ignore" requirement?

-8, first paragraph: "NSH is designed for use within operator environments."
Is there a missing "single" before "operator"?

[Ballot comment]
I have the same concern as Kathleen's DISCUSS, and would have blocked the draft on the same grounds if such a position were not already in place. The "crunchy perimeter, soft center" model of security was flawed to start with; and, even in those arenas where it was once fashionable, it's starting to be considered dated (e.g., much of the traffic inside data centers is secured using TLS -- see the recent discussions in the TLS working group for evidence of this situation). More notably, this "unconditionally trusted network zone" approach to security has led to some spectacular exploits recently (cf. https://www.wired.com/2016/04/the-critical-hole-at-the-heart-of-cell-phone-infrastructure/). Rather than explicitly fostering this model, the security section really needs to normatively disallow it.

(n.b., I reviewed version -21 of the document -- but I don't find the changes between that version and -24 to address the issue Kathleen raises)

----

Section 3 says the following about reclassification behavior:

      When the logical classifier performs re-
      classification that results in a change of service path, it MUST
      replace the existing NSH with a new NSH with the Base Header and
      Service Path Header reflecting the new service path information
      and MUST set the initial SI.  The O bit, as well as unassigned
      flags, MUST be copied transparently from the old NSH to a new
      NSH.  Metadata MAY be preserved in the new NSH.

I don't see anything here about copying the TTL. If the TTL isn't copied, you can end up with a stable (and unending) loop involving two classifiers (which seems even more damaging than usual, as the SI value won't generally survive a reclassification, right?). I would suggest adding "TTL" to the list of things that MUST be copied when reclassification occurs.

[Ballot comment]
I provided long (and somewhat grumpy!) comments on the previous version of this document -- I'd like to thank the authors, especially Carlos for addressing them.
This version is, IMO, much improved.

[Ballot comment]
Further considerations:

1) I don't really see why a TTL in the base header is needed. I mostly understand why there is the Service Index in service header, also I think there should be better mean to validate that you SFP is correct and I ideally you should really not need this. However, loop prevention can be provided by both mechanism and moreover there is probably also often a TTL in the encapsulation protocol and loop prevention should really be a function of that forwarding protocol and not the NSH.

2) I don't see why you need the type field in the base header. This is fully redundant because because all you need is the length field. If the length is 0x2 it is what you have defined as type 1 if the length field is larger it is type 2. I also don't see the need for any other types in future because you also have the version field; if you need anything else you should go or probably have to go for a new version. Note that the general probably with unnecessary redundancy is that is add complexity. If you keep this redundancy you have to separately handle and implement the case(s) where the type is 1 but the length is larger than expected. If at all you could probably just use one bit to indicate that the length field is present and if not the length is 0x2. However, saving bits does not really seem to be a concern for you, so that might not actually be an advantage.

3) sec 2.5.1
"Unassigned bit: One unassigned bit is available for future use.  This
  bit MUST NOT be set, and MUST be ignored on receipt."
Is there an actual reason to have an unassigned bit here? Because I would assume that the type already provided enough flexibility for way to extend the metadata format in any way needed.

4) Also section 2.5.1:
"  Length: Indicates the length of the variable metadata, in bytes.  In
  case the metadata length is not an integer number of 4-byte words,
  the sender MUST add pad bytes immediately following the last metadata
  byte to extend the metadata to an integer number of 4-byte words.
  The receiver MUST round up the length field to the nearest 4-byte
  word boundary, to locate and process the next field in the packet."
Your definition of the length field might be more error-prone than needed. It would probably be easier to simply define the length as 4-byte words, and the  type of course defines the content of the metadata field and as such can simply define which part of the total metadata field holds certain data of a certain type and with part is padding.

5) And finally I have to say it is unclear to me why the SFI and SI field are described as a separate header. Given they have to be present in all SFH, I would consider them as two fields of the base header. But it is after all really just an editorial issue. However, all this together with my previous comments makes the protocol spec actually much more complicated than it needs to be...

6) I also have to agree to the last comment of the tsv-art review: I think it would have been nicer to not only described the NSH but also define mappings to a set of possible encapsulations because I would assume that for each encapsulation there are a couple specific considerations that need to be made to make things work successfully. I don't think that all encapsulations can be captured by general consideration and I cannot make up my mind to go through all cases in my head to figure out if there are things that needs to be noted.

[Ballot discuss]
I have a couple of comments on the design. I know, as always in IESG review state, it's probably too late to make any changes to the actual header format, therefore most of my comments are actually in the comment section below. I still decided to note them so at least people can consider these points. However, there are a few things that I need clarification for before publication, which I note in this section:

1) Sec 2.2
"SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
  OAM procedures SHOULD discard packets with O bit set, but MAY support
  a configurable parameter to enable forwarding received SFC OAM
  packets unmodified to the next element in the chain.  Forwarding OAM
  packets unmodified by SFC elements that do not support SFC OAM
  procedures may be acceptable for a subset of OAM functions, but can
  result in unexpected outcomes for others; thus, it is recommended to
  analyze the impact of forwarding an OAM packet for all OAM functions
  prior to enabling this behavior.  The configurable parameter MUST be
  disabled by default."
This part is really unclear to me and I believe needs to be further specified. Where should this configurable parameter be? In the Context header? Why don't you just use one of the unassigned bit to indicate if an unknown (OAM) packet should be forwarded or not?
Moreover, I also disagree with this text. If there is a bit/a way to indicate if a not supported OAM packet should be forwarded or not, it should just be defined like this, while any considerations if that bit should be set or not depend on the OAM function itself and do not need to be discussed here.
Finally, it is not well explained what an OAM packet is at all. Is that a 'fake' packet that is generated by the operator to actively test the (potentially newly configured) SFP? If so, why does a SF need to know if a packet is an OAM packet or not? Usually it's a bad idea to use different kind of traffic for testing compared to what will be used in operations. Please provide more explanation here!

2) section 2.4
"An SFC-aware SF MUST receive the data semantics first in order to
  process the data placed in the mandatory context field.  The data
  semantics include both the allocation schema and the meaning of the
  included data.  How an SFC-aware SF gets the data semantics is
  outside the scope of this specification."
This is really confusing to me. I think this is what you need an actually data semantics aka type field for in the base header. Or is there an actual reason to not put this information directly in the base header where it is need but instead assuming some magical way this information may take to reach the node? If the assumption is that the SF is configured to know based of the SFI what the content of the context header has to be, you a) need to say that in the draft, and b) that's really error-prone because it's really hard to tell if the conext header actually holds the information that you need or just random crap (of course depending of the expected data type of this information). In short, I think you really need a type field somewhere here. In any case, you really need to explain this more!
Also, the text further says:
"An SF or SFC Proxy that does not know the format or semantics of the
  Context Header for an NSH with MD Type 1 MUST discard any packet with
  such an NSH..."
How does the SFC proxy know that it knows the format or not if there is no type field or identifier that indicates what the format should be?

Also, a related question from me: why is the context header present in all types of NSH if there is no use for it defined in this document yet? Why is there no fixed length NSH without a context header then?

3) Section 2.5.1:
"If multiple instances of the same metadata are included in an NSH
  packet, but the definition of that context header does not allow for
  it, the SFC-aware SF MUST process the first instance and ignore
  subsequent instances."
This seems error prone to me. If the same metadata appears multiple where it should not, that seems clearly like an error case for me. Just using the first one and proceed normally might not be the right thing to do. In any case I think such an occasion should at least be logged. If the multiple instances are just a copy of each other and carry the same information, it's probably okay to use that information and proceed. If the different instances carry different information, it maybe a bit dangerous to just use the first one and ignore others silently. In this case I would rather recommend to drop the packet...

4) In line with the second comment from the tsv-art review (thanks Wes!), I don't really understand why this documents says (sec 6) that there can be multiple next hops for the same SFP or SFs can be traversed in a different order. May understanding (from a quick look at RFC7665) would be that, if those things are needed e.g. for load balancing, then one should define different SFPs and the Classifier must have the knowledge that two SFP are equivalent and select them respectively. The reason why I'm really concerned about this is that usually a number of packets below to a flow and all packets belonging to the same flow just ideally take the same route. But usually only the Classifier has a notion of what a flow is and respectively will assign the SFI to the packets belonging to the same flow. If now any SF on the path can more or less randomly decided to forward packet belong to the same flow to one or another next nodes, I would assume that this is not only a problem for the flow, e.g. reordering, but also for SF itself in many cases.

[Ballot comment]
Further considerations:

1) I don't really see why a TTL in the base header is needed. I mostly understand why there is the Service Index in service header, also I think there should be better mean to validate that you SFP is correct and I ideally you should really not need this. However, loop prevention can be provided by both mechanism and moreover there is probably also often a TTL in the encapsulation protocol and loop prevention should really be a function of that forwarding protocol and not the NSH.

2) I don't see why you need the type field in the base header. This is fully redundant because because all you need is the length field. If the length is 0x2 it is what you have defined as type 1 if the length field is larger it is type 2. I also don't see the need for any other types in future because you also have the version field; if you need anything else you should go or probably have to go for a new version. Note that the general probably with unnecessary redundancy is that is add complexity. If you keep this redundancy you have to separately handle and implement the case(s) where the type is 1 but the length is larger than expected. If at all you could probably just use one bit to indicate that the length field is present and if not the length is 0x2. However, saving bits does not really seem to be a concern for you, so that might not actually be an advantage.

3) sec 2.5.1
"Unassigned bit: One unassigned bit is available for future use.  This
  bit MUST NOT be set, and MUST be ignored on receipt."
Is there an actual reason to have an unassigned bit here? Because I would assume that the type already provided enough flexibility for way to extend the metadata format in any way needed.

6) Also section 2.5.1:
"  Length: Indicates the length of the variable metadata, in bytes.  In
  case the metadata length is not an integer number of 4-byte words,
  the sender MUST add pad bytes immediately following the last metadata
  byte to extend the metadata to an integer number of 4-byte words.
  The receiver MUST round up the length field to the nearest 4-byte
  word boundary, to locate and process the next field in the packet."
Your definition of the length field might be more error-prone than needed. It would probably be easier to simply define the length as 4-byte words, and the  type of course defines the content of the metadata field and as such can simply define which part of the total metadata field holds certain data of a certain type and with part is padding.

4) And finally I have to say it is unclear to me why the SFI and SI field are described as a separate header. Given they have to be present in all SFH, I would consider them as two fields of the base header. But it is after all really just an editorial issue. However, all this together with my previous comments makes the protocol spec actually much more complicated than it needs to be...

5) I also have to agree to the last comment of the tsv-art review: I think it would have been nicer to not only described the NSH but also define mappings to a set of possible encapsulations because I would assume that for each encapsulation there are a couple specific considerations that need to be made to make things work successfully. I don't think that all encapsulations can be captured by general consideration and I cannot make up my mind to go through all cases in my head to figure out if there are things that needs to be noted.

[Ballot comment]
I am agreeing with Kathleen's DISCUSS.

Also, have you thought about likelyhood of introducing new versions, and if it is likely, what kind of restrictions do you want to impose on future versions (e.g. requirements on backward compatibility) and what are the criteria for bumping the version number? For example, future versions must use the same Base Header and Service Path header, but can add new mandatory fields after that. Etc.

[Ballot discuss]
First, I'd like to thank the authors and WG for your efforts in recent revisions of this draft, it has come a long way.  I still want to poke at the lack of a requirement for either integrity protection on the NSH itself or for MUSTs on protections from the transport encapsulation.  Attacks inside of a data center or single operator domains happen all too often.  The number from 2016 is up 164% as of a statistic I saw earlier today.  We can't srug this off anymore.

Security Considerations section:
First two sentences say:
  NSH is designed for use within operator environments.  As such, it
  does not include any mandatory security mechanisms.

I think you intended the first sentence to say, "within a single operator environment" as what you have now could be multiple networks managed separately with that statement.  Then for the second sentence, I know you don't have an integrity mechanism mandated, but I really think one should be.  Couldn't the path be altered and not detectable if there is no integrity checking?  This could be used to avoid security protections or to route it inappropriately through a multi-tenant environment.  Sure, the underlying protocol should provide session encryption on application traffic, but there's no reason why security shouldn't have been baked into this protocol as a requirement.

From the architecture document, the security considerations section calls attention to possible issues related to lack of integrity checking.  Since no encapsulating transport is specified with required session encryption, and the NSH addition doesn't have integrity protection, how will you meet this architecture requirement from RFC7665:

  Service Overlay:  Underneath the service function forwarders, the
        components that are responsible for performing the transport
        forwarding consult the outer-transport encapsulation for
        underlay forwarding.  Used transport mechanisms should satisfy
        the security requirements of the specific SFC deployment.  These
        requirements typically include varying degrees of traffic
        separation, protection against different attacks (e.g.,
        spoofing, man-in-the-middle, brute-force, or insertion attacks),
        and can also include authenticity and integrity checking, and/or
        confidentiality provisions, for both the network overlay
        transport and traffic it encapsulates.

It seems from this text, something should be specified for the transport encapsulation.

From the text in the draft under review:
  As with many
  other protocols, without enhancements, the NSH encapsulation could can be
  spoofed
  or otherwise modified and is subject to snooping and modification in transit.

  However, the deployment scope (as defined in [RFC7665]) of the NSH
  encapsulation is limited to a single network administrative domain as
  a controlled environment, with trusted devices (e.g., a data center)
  hence mitigating the risk of unauthorized manipulation of the
  encapsulation headers or metadata.

This is in direct conflict with the Service Overlay requirements in the Security Considerations of RFC7665.

Section 8.1
I'd like to see some MUSTs to address the concerns listed in RFC7665 for encapsulation requirements or an addition of integrity protection on NSH itself.

[Ballot comment]
This introductory text is much improved from a previous version and my comments, thanks for the update.  This helps quite a bit.

  The Network Service Header (NSH) specification defines a new protocol
  and associated encapsulation for the creation of dynamic service
  chains, operating at the service plane.  The NSH is designed to
  encapsulate an original packet or frame, and in turn be encapsulated
  by an outer transport encapsulation (which is used to deliver the NSH
  to NSH-aware network elements), as shown in Figure 1:

Section 8.1:
I don't think you need the text on BCP38.  It's a helpful recommendation in general, but I don't see how it's directly applicable to this specification.

Thank you for adding the text on Boundary protections per the SecDir review, I think this is very helpful.

[Ballot comment]
(1) While describing the MD Type field, Section 2.2. (NSH Base Header) talks about the specific scenario in which "a device will support MD Type 0x1 (as per the MUST) metadata, yet be deployed in a network with MD Type 0x2 metadata packets", and it specifies that "the MD Type 0x1 node, MUST utilize the base header length field to determine the original payload offset if it requires access to the original packet/frame."  This is the case where the node in question *does not* support MD Type 0x2, right?  If so, then the specification above seems to go against (in the last sentence of the same paragraph): "Packets with MD Type values not supported by an implementation MUST be silently dropped."  IOW, if the node doesn't support 0x2, why wouldn't it just drop the packet?


(2) Section 2.5.1. (Optional Variable Length Metadata) says that this document "does not make any assumption about Context Headers that are mandatory-to-implement or those that are mandatory-to-process.  These considerations are deployment-specific."  But the next couple of paragraphs specify explicit actions for them (mandatory-to-process):

  Upon receipt of a packet that belongs to a given SFP, if a mandatory-
  to-process context header is missing in that packet, the SFC-aware SF
  MUST NOT process the packet and MUST log an error at least once per
  the SPI for which the mandatory metadata is missing.

  If multiple mandatory-to-process context headers are required for a
  given SFP, the control plane MAY instruct the SFC-aware SF with the
  order to consume these Context Headers.  If no instructions are
  provided and the SFC-aware SF will make use of or modify the specific
  context header, then the SFC-aware SF MUST process these Context
  Headers in the order they appear in an NSH packet.

Maybe I'm confused about considerations being deployment specific vs specifying what to do here.  Can you please clarify?


(3) "SFFs MUST use the Service Path Header for selecting the next SF or SFF in the service path."  Section 6 explains most of what has to be done -- what I think is still not clear in this document is where the information in Tables 1-4 comes from.  There may be different ways for an SFF to learn that, and I would imagine that it is out-of-scope of this document.  Please say so -- maybe there's a relevant reference to rfc7665 (?).


(4) Section 11.1. (NSH EtherType) seems out of place in this document because (1) the document doesn't discuss the transport itself, and (2) it is in the IANA section... 


(5) What is the "IETF Base NSH MD Class" (Section 11.2.4)?  Ahh, I see that Section 11.2.6 talks about "the type values owned by the IETF"; it would be good to say that MD Class 0x0000 is being assigned to the IETF (in 11.2.4).



Nits:

In section 2.2. (NSH Base Header), it would be nice to have a forward reference when the Service Index is first mentioned.

It may be nice to explicitly state in the description of the MD Type field (Section 2.2) that for length = 0x2 and MD Type = 0x2, there are in fact no optional context headers. (I know there's some text about this later in section 2.5.)

"...all domain edges MUST filter based on the carried protocol in the VxLAN-gpe".  That "MUST" is out of place because the text is an example.

[Ballot comment]
Thank you for responding to Wes Eddy's TSV-ART review of -19 (and, of course, for making text changes that seemed appropriate).

It seems to me that you describe expectations about the applicability of NSH in various places in the document, and in various ways. You might consider (for example) pulling the common elements of statements like (from Section 5)

  Within a managed administrative domain, an operator can ensure that
  the underlay MTU is sufficient to carry SFC traffic without requiring
  fragmentation.  Given that the intended scope of the NSH is within a
  single provider's operational domain, that approach is sufficient.

and (from Section 8)

  NSH is designed for use within operator environments.  As such, it
  does not include any mandatory security mechanisms.  As with many
  other protocols, without enhancements, the NSH encapsulation can be
  spoofed and is subject to snooping and modification in transit.

  However, the deployment scope (as defined in [RFC7665]) of the NSH
  encapsulation is limited to a single network administrative domain as
  a controlled environment, with trusted devices (e.g., a data center)
  hence mitigating the risk of unauthorized manipulation of the
  encapsulation headers or metadata.  This controlled environment is an
  important assumption for NSH.  There is one additional important
  assumption: All of the service functions used by an operator in
  service chains are assumed to be selected and vetted by the operator.

into one section describing the applicability of NSH, appearing MUCH earlier in the document (the most detailed description of your expectations looks like it appears in the Security Considerations section, but parts of that description are applicable to the Fragmentation Considerations section, which appears three sections earlier in the document). The reader would have your intended applicability in mind much earlier and more clearly, and you could just invoke your expectations by reference when you need to explain how they apply elsewhere in the document, so the expectations in play would be consistent across mentions throughout the document.

I'm still bothered that this document doesn't explicitly mention ICMP blocking as a problem for PMTUD with IP encapsulations. We're just not good at path MTU discovery, so it seems useful to call this out explicitly when a document expects to use PMTUD. That way, people who use NSH will know to check for ICMP blocking on their networks before they receive their first trouble reports. This almost reached my threshold for balloting Discuss, so I'd hope you folks would consider that.

I see that the applicability of NSH includes encapsulations that don't provide a path MTU discovery mechanism, and that your resolution for those encapsulations is to log events when a "too big" packet is dropped. Could you educate me, as to whether all encapsulations detect that this is happening? It might be that encapsulations are using a fixed maximum MTU by definition, so that what you're logging is an attempt to send a payload that violates the protocol definition of the encapsulation, but I don't know that that's true in all cases, so thought I should ask.

I saw a suggestion from Joe Touch (in a response to the TSV-ART review) to consider looking at the terminology developed for draft-ietf-intarea-tunnels. I didn't see a reply to that suggestion, and I didn't see a reference to draft-ietf-intarea-tunnels in -24 - was this considered?

(I'm also asking because I want to keep track of whether people applying encapsulations find that document useful, of course)

(Joe's follow-up is at https://mailarchive.ietf.org/arch/msg/tsv-art/CsdWwR9B5_AB64D0eFl-KIE7_NA)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sfc-nsh-18. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are six actions which we must complete.

We will create a new registry page called the Network Service Header (NSM) Parameters registry.

First, a new registry will be created on the newly created Network Service Header (NSM) Parameters registry page called the NSH base Header Bits registry. This registry will be managed via Standards Action as defined in [ RFC8126 ]. There are initial registrations in the new registry as follows:

Base Description Reference
Header Bit
--------------+----------------------+------------------------
Bit 2 O (OAM) bit [ RFC-to-be ]
Bit 3 Unassigned [ RFC-to-be ]
Bits 16-19 Unassigned [ RFC-to-be ]

IANA Question --> Are bits 0-1, 4-15 and greater than 19 not part of the NSH Base Header? Should they be accounted for in this new registry?

Second, a new registry will be created on the newly created Network Service Header (NSM) Parameters registry page called the NSH Version registry. This registry will be managed via Standards Action as defined in [ RFC8126 ]. There are initial registrations in the new registry as follows:

Version Description Reference
----------+---------------------------+-------------------
00b This protocol version [ RFC-to-be ]
01b Reserved [ RFC=to-be ]
10b Unassigned
11b Unassigned

IANA Question --> Should different or alternative text replace the words "This protocol version" in the new registry?

Third, a new registry will be created on the newly created Network Service Header (NSM) Parameters registry page called the MD Type registry. This registry will be managed via IETF Review as defined in [ RFC8126 ]. There are initial registrations in the new registry as follows:

+----------+-----------------+---------------+
| MD Type | Description | Reference |
+----------+-----------------+---------------+
| 0x0 | Reserved | [ RFC-to-be ] |
| | | |
| 0x1 | NSH MD Type 1 | [ RFC-to-be ] |
| | | |
| 0x2 | NSH MD Type 2 | [ RFC-to-be ] |
| | | |
| 0x3..0xE | Unassigned | |
| | | |
| 0xF | Experimentation | [ RFC-to-be ] |
+----------+-----------------+---------------+

Fourth, a new registry will be created on the newly created Network Service Header (NSM) Parameters registry page called the MD Class registry. This registry will be managed via the following rules:

0x0000 to 0x01ff: IETF Review
0x0200 to 0xfff5: Expert Review
0xfff6 to 0xfffe: Experimental
0xffff: Reserved

There is a single, initial registration in the new registry as follows:

+-----------+-----------------------------+----------------+
| MD Class | Meaning | Reference |
+-----------+-----------------------------+----------------+
| 0x0000 | IETF Base NSH MD Class | [ RFC-to-be ] |
+-----------+-----------------------------+----------------+

Fifth, a new registry will be created on the newly created Network Service Header (NSM) Parameters registry page called the Next Protocol registry. This registry will be managed via Expert Review as defined in [ RFC8126 ]. There are initial registrations in the new registry as follows:

+---------------+--------------+---------------+
| Next Protocol | Description | Reference |
+---------------+--------------+---------------+
| 0x0 | Unassigned | |
| | | |
| 0x1 | IPv4 | [ RFC-to-be ] |
| | | |
| 0x2 | IPv6 | [ RFC-to-be ] |
| | | |
| 0x3 | Ethernet | [ RFC-to-be ] |
| | | |
| 0x4 | NSH | [ RFC-to-be ] |
| | | |
| 0x5 | MPLS | [ RFC-to-be ] |
| | | |
| 0x6..0xFD | Unassigned | |
| | | |
| 0xFE | Experiment 1 | [ RFC-to-be ] |
| | | |
| 0xFF | Experiment 2 | [ RFC-to-be ] |
+---------------+--------------+---------------+

Sixth, a new registry will be created on the newly created Network Service Header (NSM) Parameters registry page called the IETF Assigned Optional Variable Length Metadata Type registry. This registry will be managed via Standards Action as defined in [ RFC8126 ]. There are no initial registrations in the new registry.

The IANA Services Operator understands that these six actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-08-25):

From: The IESG
To: IETF-Announce
CC: sfc-chairs@ietf.org, sfc@ietf.org, "Joel M. Halpern" , akatlas@gmail.com, draft-ietf-sfc-nsh@ietf.org, jmh@joelhalpern.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Network Service Header (NSH)) to Proposed Standard


The IESG has received a request from the Service Function Chaining WG (sfc)
to consider the following document: - 'Network Service Header (NSH)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-08-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes a Network Service Header (NSH) inserted onto
  packets or frames to realize service function paths.  NSH also
  provides a mechanism for metadata exchange along the instantiated
  service paths.  NSH is the SFC encapsulation required to support the
  Service Function Chaining (SFC) architecture (defined in RFC7665).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2905/
  https://datatracker.ietf.org/ipr/2545/
  https://datatracker.ietf.org/ipr/2108/
  https://datatracker.ietf.org/ipr/2547/
  https://datatracker.ietf.org/ipr/2735/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7665: Service Function Chaining (SFC) Architecture (Informational - IETF stream)
    draft-quinn-sfc-nsh: Network Service Header (None - )

1) As Acee already noted, receivers of unassigned flags MUST ignore the value.  There are a couple places to fix this.

2) Given the consensus in NVO3 and that VXLAN-GPE will be progressed as an informational document described an alternative that was not selected for standardization, I would prefer a different example in Sec 6.1 Table 1.

3) In Sec 7.1, there is a sentence "In some cases they may terminate, and be able to inspect encrypted traffic."  Unless there is a strong technical need to point this out, I would pick a different example.  There is a great deal of current controversy and discussion happening in TLS currently - and this is likely to trigger that discussion unnecessarily.

4) I am happy to see that IEEE (https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries) is now showing the EtherType 0x894F as referring to this draft.  Thanks!

Essay format shepherd writeup for draft-ietf-sfc-nsh-18

The writeup is being prepared by one of the working group co-chairs, Joel Halpern.  It is prepared for consideration by the community, the IESG, and the responsible AD, Alia Atlas.

This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths.  NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665).

The working group is requesting that this packet format and handling information be published as a Proposed Standard RFC.  It defines an interoperable mechanism to achieve the stated goals.

The working group has had many discussions on this document.  Many individuals from many companies have helped bring together this solution.  Over the last 9 months significant effort has gone into fixing issues raised by earlier reviews.  While there is still some disagreement (such as on the fact that the WG selected TTL mechanism is a compromise with some accepted imperfections), all technical limitations are identified in the document and dealt with in fashions acceptable to the rough consensus of the working group.

There are multiple implementations of this work, some from open source and some proprietary.

As required by IETF process, all front page editors have explicitly confirmed that there is no undisclosed relevant IPR.

This document does normatively reference and build upon RFC 7665, which is an informational RFC published by the working group.

Second early AD review:


Minor:
a) In Sec 3.2, it says "MD Type: indicates the format of NSH beyond the mandatory Base Header

  and the Service Path Header.  MD Type defines the format of the
  metadata being carried.  Please see IANA Considerations section
  below.

  NSH defines two MD types:

  0x1 - which indicates that the format of the header includes fixed
  length context headers (see Figure 4 below).

  0x2 - which does not mandate any headers beyond the Base Header and
  Service Path Header, but may contain optional variable length context
  information."

  This is an 8-bit field and from the IANA considerations appears to be intended to be an integer.  This implies that it isn't possible for an NSH packet to have both the fixed length context headers and the TLV context information.    Why is that the case?  Since the MD Type 1 is MTI, it seems to provide an excellent way of ensuring that information can be understood by every entity, and then TLV information could be used for additional information to be passed along.

Is there a reason or a conversation when this approach was ruled out?

b) Sec 3.2:  The Next Protocol field defines different values for IPv4 and IPv6.  Why isn't there simply a value for IP that the enclosed IP packet can then self-identify as to its version?    Separately, can you please name the Next Protocol field to either something that indicates what types of next protocol might be carried or at least a less generic name so that intelligent reuse is possible?

c) Sec 12.2.5:  I am concerned about all values in the NSH Base Header Next Protocol field being "Standards Action".  Any new encapsulation now will have to get allocations from potentially EtherType, NSH Next Protocol, IP Next Protocol, and possibly more if the NSH Next Protocol field isn't reused.  I would strongly recommend at least having part of the range available for Specification Required which will also require guidance to be provided for an expert reviewer.

d) Sec 3.3:  "Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services and the new
  decremented SI value MUST be used in the egress NSH packet."
Is this "decremented by 1"' or "strictly decreasing" or something else?  Is it possible for the SI along a given SPI to ever increase (for instance for an intentional loop)?  Please clarify.
  This same issue appears in Sec 4 bullet 3.

e) Sec 8.2:  Is there a reason that removal of metadata isn't mentioned?  Presumably, an SF can remove a piece of metadata if it is no longer needed by the SFP for the remainder of the processing?

f) Sec 9:  "Further, as  described in [section 8.1], operators can and should use indirect
  identification for personally identifying information, thus
  significantly mitigating the risk of privacy violation."
The reference of Section 8.1 doesn't describe this.  Can you please update the reference?

g) Sec 12.1:  I continue to be concerned about the reuse of an EtherType that was allocated initially for another purpose.  Has the IEEE ok'd this and assigned ownership to the IETF?

h) Sec 12.2.3:  The description for MD Type 1 and MD Type 2 should be more accurate and not the same!  "Indicates fixed metadata attached" and "Indicates TLV metadata may be attached"' or something similar.

i)Sec 12.2.4 MD Class Registry:  This defines Expert Review for a range but provides no guidance to the expert on how to evaluate or make decisions.  That is needed.  Given the need to potentially understand the different meanings of the meta-data, I think that Specification Required would be preferable to Expert Review.