Subject: [sfc] Update to draft-farrel-sfc-convent after shepherd review

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 Dec 2017 14:53:02 -0000

Hi,

Tal did a review as document shepherd. This resulted in the following changes..

Requirements Language
OLD
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
NEW
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
END

---

Section 1:
OLD
   This document defines a mechanism for metadata to be carried on an
   SFP without the need for payload data.  This may enable diagnosis and
   monitoring of SFPs, and coordination between SFC-aware SFIs, without
   the need for traffic to be flowing, and without the need to rewrite
   data packets to insert what might be substantial amounts of metadata.
NEW
   This document defines a mechanism for metadata to be carried on an
   SFP without the need for payload data.  This mechanism enables
   diagnosis and monitoring of SFPs, and coordination between SFC-aware
   SFIs.  The mechanism can be applied without the need for traffic to
   be flowing, and if traffic is flowing it can be applied without the
   need to insert what might be substantial amounts of metadata into
   data packets (an operation that may be costly in some hardware).
END

---

Section 1
OLD
   This function is achieved by defining a new value for the NSH "Next
   Protocol" field to indicate "None".  Like any NSH packets, such
   packets are contained within the SFC-enabled domain.
NEW
   This document describes how this function is achieved through the use
   of a new value for the NSH "Next Protocol" field to indicate "None".
   Like any NSH packets, such packets are contained within the SFC-
   enabled domain.
END

Section 2.1:

OLD
   When the next protocol is "None" the rest of the NSH still has
   meaning and, in particular, the metadata carried in the NSH may still
   be present.
NEW
   When the next protocol is "None" the rest of the NSH still has
   meaning and, in particular, the metadata carried in the NSH may still
   be present.  It is not intended that a packet with next protocol set
   to "None" is sent with no metadata (see Section 3).  Thus, an SFC-
   aware node SHOULD NOT create a packet with next protocol set to
   "None", Metadata Type set to 0x2, and with NSH Length of 0x2.
END

---

Tal also asked about the lower case "may"s in Section 3. I reviewed and think
they're all good.

Cheers,
Adrian

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 29 December 2017 14:46
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-farrel-sfc-convent-05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Service Function Chaining WG of the IETF.
> 
>         Title           : Operating the Network Service Header (NSH) with Next
Protocol
> "None"
>         Authors         : Adrian Farrel
>                           John Drake
> 	Filename        : draft-farrel-sfc-convent-05.txt
> 	Pages           : 11
> 	Date            : 2017-12-29
> 
> 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 IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-farrel-sfc-convent-05
> https://datatracker.ietf.org/doc/html/draft-farrel-sfc-convent-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-farrel-sfc-convent-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt