Operating the Network Service Header (NSH) with Next Protocol "None"
draft-farrel-sfc-convent-06

[Ballot comment]
Thanks for addressing my discuss by adding a new section on congestion management! I was still hoping to see more concrete guidance e.g. simlar to what RFC8085 recommends: "... not sending on average more than one UDP datagram per RTT to a destination". However, this might not be suitable for all sfc use cases and therefore the high level guidance as now provided might be sufficient as well.

-----
Old comment
------
I think this document should update RFC8300 as it does not only register an new protocol but also changes some of the process for this specific case.

[Ballot comment]
Thanks for the security considerations, I think these look good for what this document should address adding the possible considerations for metadata only NSH.  Integrity protection, authentication and other things lacking in SFC and NSH should be addressed in other documents (and it's sadly not, but this isn't the document for that).

[Ballot comment]
In a comment vying for least useful comment ever:
'Packets are classified at the SFC network ingress boundaries by
  Classifiers (section 4.4 of [RFC7665]) and have an NSH applied to
  them."
I suspect this should be "and have *a* NSH applied to them".
(hey, I did warn you)

[Ballot comment]
  The need to protect the metadata is not modified by this document and
  forms part of the NSH definition found in [I-D.ietf-sfc-nsh].
Nit: I wouldn't limit this to encryption. If you care about integrity/data origin authentication, then encryption may not supply that,

[Ballot discuss]
This spec enables an SC node to create new packets and therefore must provide congestion control consideration to avoid network overload from these packets, e.g. in the simplest case requiring a maximal sending rate/minimal time interval between to packets.

I also requested an additional TSV-ART review for further feedback and recommendations for a potential solution.

[Ballot comment]
I think this document should update RFC8300 as it does not only register an new protocol but also changes some of the process for this specific case.

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

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

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the NSH Next Protocol registry on the Network Service Header (NSH) Parameters registry page located at:

https://www.iana.org/assignments/nsh/

a single, new value is to be registered as follows:

Next Protocol: [ TBD-at-Registration ]
Description: None
Reference [ RFC-to-be ]

We note that the authors have requested that the value 0x00 be used for this registration.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action 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 the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-01-31):

From: The IESG
To: IETF-Announce
CC: draft-farrel-sfc-convent@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, akatlas@gmail.com, Tal Mizrahi , tal.mizrahi.phd@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Operating the Network Service Header (NSH) with Next Protocol "None") to Proposed Standard


The IESG has received a request from the Service Function Chaining WG (sfc)
to consider the following document: - 'Operating the Network Service Header
(NSH) with Next Protocol "None"'
  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 2018-01-31. 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 the use of the Network Service Header (NSH)
  in a Service Function Chaining (SFC) enabled network with no payload
  data and carrying only metadata.  This is achieved by defining a new
  NSH "Next Protocol" type value of "None".

  This document illustrates some of the functions that may be achieved
  or enhanced by this mechanism, but it does not provide an exhaustive
  list of use cases, nor is it intended to be definitive about the
  functions it describes.  It is expected that other documents will
  describe specific use cases in more detail and will define the
  protocol mechanics for each use case.





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

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


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Tal Mizrahi. The responsible Area Director is Alia Atlas.

This document describes the use of the Network Service Header (NSH) in a Service Function Chaining (SFC) enabled network with no payload data and carrying only metadata.  This is achieved by defining a new NSH "Next Protocol" type value of "None". This new capability is proposed as a standard extension to NSH.

2. Review and Consensus

The extension is straightforward, and there was no difficulty in coming to consensus. Because of its simplicity, and since there was good acceptance of the draft, the WG chairs decides to proceed directly to WG last call without going through a WG adoption process. A fair number of people have reviewed the document and sent comments to the SFC mailing list, and the authors have addressed the comments that required addressing. There seems to be consensus in the working group that the document is ready for publication.

3. Intellectual Property

There are not IPR disclosures on the document. Each of the authors has confirmed that they are not familiar with any IPR that applies to this document , in conformance with BCPs 78 and 79.

4. Other Points

The document requests an IANA allocation that requires expert review. The SFC WG chairs are both listed as experts for this specific IANA registry, and have reviewed the draft.