Subject: [sfc] WG Last Call for draft-farrel-sfc-convent

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Nov 2017 16:13:51 -0500

This draft
https://tools.ietf.org/html/draft-farrel-sfc-convent-02

has been rpesented at several IETF meetings.  It provides a small 
elaboration on the NSH document.  There seemed to be good working group 
acceptance of the work, although we never formally adopted it.

The WG Chairs have determined that it makes sense to go directly to a WG 
last call on this document.
Given that there are two last calls an two calls for working group 
adoption (see following emails) we are allowing 3 weeks for these calls.

Please respond with either support or objection to the WG delivering 
this document to our area director for publication as a Proposed 
Standard RFC.

We need to see feedback.  Silence does not imply consent.
We would prefer feedback with content.

Thank you,
Joel (& Jim)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 29 Nov 2017 17:12:29 -0500

Joel,

I support the WG delivering this draft for publication. On review, it looks
ready to go.

Cheers,
Andy

On Wed, Nov 29, 2017 at 4:13 PM, Joel M. Halpern <[email-masked]>
wrote:

> Please respond with either support or objection to the WG delivering this
> document to our area director for publication as a Proposed Standard RFC.
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: <[email-masked]>
Date: Thu, 30 Nov 2017 08:54:37 +0000

Hi all, 

I support. 

Below some comments that can be easily addressed by Adrian. 
FWIW, a version with revision marks is available at: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-farrel-sfc-convent-03-rev%20Med.pdf 

* Section 1:

(1) nit: 

OLD:
   Metadata may be used to enhance or enable the
   function preformed by SFC-aware SFs, may enable coordination and data
            ^^^^^^^^^^
   exchange between SFIs, or may be used to assist a network operator in
   the diagnosis and monitoring of an SFP.  

NEW:
   Metadata may be used to enhance or enable the
   function performed by SFC-aware SFs, may enable coordination and data
   exchange between SFIs, or may be used to assist a network operator in
   the diagnosis and monitoring of an SFP.  

(2) Insist this is not a new behavior: 

OLD: 
   Such packets are contained within the SFC-enabled domain.
NEW:
   Like any NSH packets, such packets are contained
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
   within the SFC-enabled domain.

(3) Point to the section where same use cases are described:

OLD: 
   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.  

NEW:
   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 (refer to Section 5). 
                          ^^^^^^^^^^^^^^^^^^^^ 

(4) Delete this text: 

It is expected that other documents will
   describe specific use cases in more detail and will define the
   protocol mechanics for each use case.

(5) Add this text at the end of the section:

NEW:
This document uses the terms defined in [RFC7665] and [I-D.ietf-sfc-nsh].

* Section 2:

(1) Merge Sections 2 and 3 + change the title accordingly

OLD: 
The Network Service Header

NEW:
Next Protocol 'None': Specification & Behavior

(2) NSH is already cited in the document

OLD:
   The NSH is defined in [I-D.ietf-sfc-nsh].  It includes a field called
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   "Next Protocol" that is used to indicate the nature of the payload

NEW:

   The NSH includes a field called "Next Protocol" that is used to 
   indicate the nature of the payload

(3) 

OLD:
  This document defines a new value for the "Next Protocol" field.

NEW:
  This document defines TBD1 value for the "Next Protocol" field.

* Section 3:

(1) 

OLD: 
  3.  Processing Rules

NEW: 
  2.2.  Processing Rules

(2) Before describing the processing behavior, the reader may first need to know about the triggers for sharing such information. Please position this two paragraphs at the beginning of the section: 

   A packet with no payload data may be inserted at the head end of an
   SFP (such as at a Classifier) and may be easily forwarded by an SFF
   or SFI on the SFP using the processing rules defined in
   [I-D.ietf-sfc-nsh].

   A packet with no payload may also be generated by an SFC-aware SFI as
   a result of processing an incoming packet (i.e., triggered by a
   condition arising from processing a normal NSH packet with a
   payload).  In such cases, the SPI/SI can be inherited from the
   original packet or can be set according to information supplied
   through the control plane, or management plane, or indicated by
   information carried in the metadata of the data packet.  This
   document does not further specify the triggers to generate an NSH
   packet with a "Next Protocol" set to "None".

(3) Insert this NEW text right after the first two ones: Some setup is needed before a node can generate a packet with None: 

NEW:
   An SFC-aware node may be instructed by the control plane about 
   the conditions under which such packets are to be generated. 
   Further, the control plane is responsible for providing the required
   information to generate the corresponding NSH packet (e.g., SFP 
   Identifier to use, TTL).

(4) Update this text to insist that one or multiple piece of metadata can be inserted:

OLD:
   o  MUST create a packet carrying an NSH and the desired metadata

NEW:
   o  MUST create a packet carrying an NSH and the desired metadata; one or more metadata fields may be included.

(5) 

   A transit node (SFF, SFI, or Classifier) receiving a packet with
   "Next Protocol" indicating "None" MUST NOT attempt to parse or
   process beyond the end of the NSH, but SHOULD process the NSH and the
   metadata as normal.

I wonder whether "normal" can be expanded a little bit here. For example, indicate what to do if an intermediate node is instructed to strip a metadata, and no metadata field is left. Should the packet be forward even if no metadata field is included of it should stop forwarding.

(6) Add this text at the end of the section:

NEW:
   In deployments where Next-Protocol "None" is not desired, 
   administrators SHOULD instruct SFC-aware nodes to discard
    packets with Next-Protocol "None".   

* Section 6

(1) Simplify this text: 

OLD:

   The procedures for handling NSH fields with unknown values are set
   out in [I-D.ietf-sfc-nsh].  In particular, section 2.2 of
   [I-D.ietf-sfc-nsh] describes how elements of an SFC enabled network
   handle unknown values of the "Next Protocol" field.

   SFC-aware nodes that do not understand the meaning of a value
   contained in the "Next Protocol" field of the NSH are unable to parse
   the payload.  Such nodes silently drop packets with unknown "Next
   Protocol" values unless explicitly configured to forward them.

NEW:

   SFC-aware nodes that do not understand the meaning of a value
   contained in the "Next Protocol" field of the NSH are unable to parse
   the payload.  Such nodes silently drop packets with unknown "Next
   Protocol" values unless explicitly configured to forward them 
   (Section 2.2 of [I-D.ietf-sfc-nsh]).

(2) 

   o  SFC Proxies will drop the packets

   o  SFIs will most likely drop the packets

- Use the same wording for SFC-aware SFs and SFC proxies given that both can update/insert/strip metadata.

(3)

   o  Reclassifiers  will most likely drop the packets

- Purely speaking, these are classifiers according to the SFC architecture.

(4) Not sure to understand this text: 

   It is a
   general processing rule for all forwarders that they SHOULD NOT
   attempt to send packets with zero length, and packets with the NSH
   "Next Protocol" set to "None" are expected to have zero payload
   length.

(5) Please delete this text:

In any case, SFC-aware nodes at the end of an SFP MUST NOT
   forward packets with "Next Protocol" set to "None".

Because it is redundant with the text in Section 3:

Such nodes MUST NOT forward packets with "Next Protocol"
   indicating "None" even if there are some bytes after the NSH.

* Section 5:

(1) Please add this text as a preamble: Communicating the exact value of a given context information is only one step in the process. Some setup is required to instruct SFC-aware nodes about allowed context information to share, how to consume it, what do after consuming it, and so on. 

NEW:
     As discussed in [I-D.ietf-sfc-control-plane], the control plane is 
     responsible for instructing SFC-aware nodes about the metadata allowed
     for a given SFP, the semantic of such data, the behavior to follow 
     after consuming metadata, the order of processing metadata, etc. 
     Such considerations are assumed to be in place within an SFC-enabled
     domain. The following focuses on the provisioning of allowed metadata
     values for a given SFP.  

* Section 5.1: the metadata can be provisioned on other nodes than an SFC-aware SF:

OLD: 
   Per-SFP metadata is metadata that applies to an SFP and any data
   packets on that SFP.  It does not need to be transmitted with every
   packet, but can be installed at the SFIs on the SFP and applied to
   all packets on the SFP.  It could be installed by inclusion in the
   NSH of a data packet sent on the SFP, by out of band control or
   management plane mechanisms, or by separate metadata-only packets
   using "Next Protocol" set to "None" as described in this document.

   Per-SFP metadata-only packets may be sent along the path of an SFP
   simply by setting the correct SPI in the NSH, and setting the SI to
   the correct value for the hop of the SFP at which the metadata is to
   be introduced.  Classifiers and reclassifiers  will know the correct
   SI values to be used from information supplied by the control or
   management plane as is the case for NSH packets with payload data.

NEW:
   Per-SFP metadata are metadata that apply to an SFP and any data
                    ^^^^              ^^^^^^  
   packets bound to that SFP.  It do not need to be transmitted with every
                                  ^^
   packet, but can be provisioned on the classifier, SFC-aware SFs, and SFC-aware proxies for this SFP and applied to
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   all packets on the SFP.  It could be provisioned by inclusion in the
                                        ^^^^^^^^^^^
   NSH of a data packet sent on the SFP, by out of band control or
   management plane mechanisms, or by separate metadata-only packets
   using "Next Protocol" set to "None" as described in this document.

   Per-SFP metadata-only packets may be sent along the path of an SFP
   by setting the correct SPI in the NSH, and setting the SI to
   the correct value for the hop of the SFP at which the metadata is to
   be introduced.  SFC-aware nodes (e.g., Classifiers)  will know the correct
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
   SI values to be used from information supplied by the control or
   management plane as is the case for NSH packets with payload data.

* Section 5.2: Idem as Section 5.1

* Section 5.6: 

OLD: 
   Per-packt metadata is metadata that applies specifically to a single
       ^^^^^^         ^^               ^^^^^^^^  
   payload packet.  It informs an SFI how to handle the payload packet,
   and does not apply to any other packet.

   The mechanisms described in this document are not applicable to per-
                ^                            ^^^^
   packet metadata because, by definition, if the "Next Protocol"
   indicates "None" then there is no packet following the NSH for the
   metadata to be associated with.

NEW:
   Per-packet metadata are metadata that apply specifically to a single
   payload packet.  It informs an SFI how to handle the payload packet,
   and does not apply to any other packet.

   Evidently, the mechanism described in this document is not applicable to per-
   ^^^^^^^^^^
   packet metadata because, by definition, if the "Next Protocol"
   indicates "None" then there is no packet following the NSH for the
   metadata to be associated with.

* Section 6: SHOULD be would be more appropriate here: 

OLD:
   The amount of packets with "Next Protocol" set to "None" on an SFP
   MAY be rate limited at any point on the SFP to provide additional
   security.

NEW:
   The amount of packets with "Next Protocol" set to "None" on an SFP
   SHOULD be rate limited at any point on the SFP to provide additional
   security.

* Section 7: 

OLD: 

   IANA has been requested to create a registry of "Next Protocol"
   values in [I-D.ietf-sfc-nsh].  This document requests IANA to
   allocate a value from that registry to indicate "None" (TBD1 in this
   document).

   It is strongly suggested that a value of 0 (zero) be assigned.

NEW:

   This document requests IANA to allocate a value from the 
   "NSH Next Protocol" registry at https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol
   (TBD1 in this document):

   Next  Protocol 	Description 	Reference
      0x00      	      None             [This-Document]

Thank you.
Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
> Envoyé : mercredi 29 novembre 2017 22:14
> À : [email-masked]
> Objet : [sfc] WG Last Call for draft-farrel-sfc-convent
> 
> This draft

---

From: <[email-masked]>
Date: Thu, 30 Nov 2017 08:55:47 +0000

WG,

I too believe draft-farrel-sfc-convent is in good shape and ready to move on.

Cheers,

Christian.

-----Message d'origine-----

This draft

has been rpesented at several IETF meetings.  It provides a small elaboration on the NSH document.  There seemed to be good working group acceptance of the work, although we never formally adopted it.

The WG Chairs have determined that it makes sense to go directly to a WG last call on this document.
Given that there are two last calls an two calls for working group adoption (see following emails) we are allowing 3 weeks for these calls.

Please respond with either support or objection to the WG delivering this document to our area director for publication as a Proposed Standard RFC.

Thank you,
Joel (& Jim)

_________________________________________________________________________________________________________________________

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

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 30 Nov 2017 09:03:35 +0000

Hi.

I support the proposal as well, and want to remark I am glad to see our most esteemed chairs taking an approach like this for the sake of agility.

Be goode,
--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 30/11/2017, 09:56, "sfc on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    WG,

    Cheers,

    Christian.

    -----Message d'origine-----
    De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
    Envoyé : mercredi 29 novembre 2017 22:14
    À : [email-masked]
    Objet : [sfc] WG Last Call for draft-farrel-sfc-convent

    This draft

    Thank you,
    Joel (& Jim)

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Dave Dolson <[email-masked]>
Date: Thu, 30 Nov 2017 16:15:41 +0000

I support adoption.

I also support WGLC.

However, I found the intended behavior of service functions (SFIs) to be a bit difficult to understand.
I believe the intent is to leave it free to the implementer and operator (per "local policy"), but I feel like I had to read between the lines.

Could we add a paragraph like this somewhere in section 3?
NEW:
   For backwards compatibility, SFIs are permitted to discard payload-none NSH packets. 
   However, SFIs SHOULD forward payload-none NSH packets (according to the normal rules of decrementing SI and sending to SFF).
   Furthermore, SFIs MAY utilize or augment the metadata in payload-none packets.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, November 29, 2017 4:14 PM
To: [email-masked]
Subject: [sfc] WG Last Call for draft-farrel-sfc-convent

This draft

Thank you,
Joel (& Jim)

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 30 Nov 2017 09:25:27 -0800

Dear All,
I am glad that this document has been WG LC'ed. I support progressing it
but have reservations about section 5.4 that discusses use of None value in
OAM. Below are my comments to the section 5,4:

   - "If OAM information is carried in packets that also include payload data,
   that information must be carried in metadata."

As noted in section 4 of draft-brockners-sfc-ioam-nsh
<https://tools.ietf.org/html/draft-brockners-sfc-ioam-nsh-00#section-4>,
authors consider encapsulating iOAM data after the SFC NSH using iOAM
protcol type. And what is 'must' in this statement - normative or mere
observation?

   - "Sending OAM separate from (but interleaved with) packets that carry
   payload data ..."

This is the case when specially constructed test packets injected in the
network solely for purpose of performing OAM functions, e.g. performance
measurement. This is active OAM, according to RFC 7799, and, as discussed
in draft-wang-sfc-multi-layer-oam
<https://tools.ietf.org/html/draft-wang-sfc-multi-layer-oam-10> and
presented in the meeting in Singapore, there are different ways to perform
active OAM over SFC NSH domain. Because progress
of draft-wang-sfc-multi-layer-oam and other active SFC OAM drafts is
awaiting new charter of the SFC WG, including None protocol solution in
standard RFC, in my opinion, creates unnecessary and unhelpful multiplicity
of options that will complicate implementations and may cause
interoperability issues. All of that may be avoided if authors decide to
take the section 5.4 out from the document and have the discussion of
active OAM in scope of discussion of draft-wang-sfc-multi-layer-oam.

Regards,
Greg