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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 Dec 2017 18:36:35 -0000

Hey Med,

Thanks for the review.

> Below some comments that can be easily addressed by Adrian.

Yes. Easy. In line.

> * 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.

Nice :-)

> (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.

Ack

> (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).
>                           ^^^^^^^^^^^^^^^^^^^^

Something like that, yes.

> (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.

Is this harmful? I suppose it is apple pie.

> (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].

This is true and it is harmless to add it. Not sure it is necessary given the
way the text is written, but I'll add it.

> * Section 2:
> 
> (1) Merge Sections 2 and 3 + change the title accordingly
> 
> OLD:
> The Network Service Header
> 
> NEW:
> Next Protocol 'None': Specification & Behavior

I think I stick at this one. Merging the sections but not changing the text in
any other way is just making a major section into a subsection. I don't see the
value.
OTOH, I like the separation as it stands.

> (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

OK

> (3)
> 
> OLD:
>   This document defines a new value for the "Next Protocol" field.
> 
> NEW:
>   This document defines TBD1 value for the "Next Protocol" field.

OK. Needs a little more fiddling to fix up.

> * Section 3:
> (1)
> OLD:
>   3.  Processing Rules
> NEW:
>   2.2.  Processing Rules

As above.

> (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".

Yeah, that works.

> (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).

I agree that these are possible scenarios, but there are many others.

I could add this as an example of how stuff might be, but that leaves me
wondering how many other examples I'd need to add. I prefer to leave this as an
exercise for the implementer - it is also dependent on the use case.

> (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.

What is a "metadata field"? I went back to draft-ietf-sfc-nsh and I think the
grammar is correct.

> (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.

Yes, we can add that case.
Any other cases on your mind?

> (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".

Would it be better to have...

    In deployments where use of Next-Protocol "None" is not
    desired, administrators SHOULD instruct SFC-aware nodes to
    not create such packets and 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]).

OK

> (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.

This isn't about metadata, it's about unknown Next Protocol values.
So an SFC Proxy exists to protect the non-SFC-aware SFI, so it really will drop
the packets and would never be configured to pass packets to the SFI.
But an SFC-aware SFI acts to protect itself so it can handle unknown Next
Protocol values any way it wants and it *might* be configured (for some SFs) to
simply 'forward' them back to the SFF.

I think the text stands.
 
> (3)
> 
>    o  Reclassifiers  will most likely drop the packets
> 
> - Purely speaking, these are classifiers according to the SFC architecture.

Yeah.
But really? Do we write "Classifiers or functions of other components that
provide non-initial classification (or reclassification)"? :-)

> (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.

How about...

    It is a general processing rule for all packet forwarding engines that
    they should not attempt to send packets with zero length. Packets
    with the NSH "Next Protocol" field set to "None" are expected to
    have zero payload length and so should not be forwarded once the
    NSH has been stripped.

> (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.

Hmm, can't say it often enough :-)
But will make this:

   In any case, as noted in Section 3, SFC-aware nodes at the end
   of an SFP do not forward packets with "Next Protocol" set to
   "None".

> * 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.

But this is not the only case. It is perfectly possible that an SFC aware node
(e.g., an SFI) is built to know what metadata to create without requiring
interference from a control plane.

Anyway, I hope that this document doesn't need to discuss all of the application
scenarios of metadata.

> * 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.

This brings up two issues: one big and one small.

The small one is the use of the singular for "metadata". You are, of course,
correct for "proper English", but fortunately English is a living language and
"data" is now used as a singular noun.

The larger issue is, I think, is a confusion. What this text is talking about is
installing the metadata at the point of consumption, not at the point of
injection. My understanding of metadata is that it is consumed only at SFIs.

> * 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.

Rule#97 of "How to write good text" says that you should never say "evidently"
or "obviously" in case you insult your reader. :-)

> * 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.

While I sympathise, I don't know that "SHOULD...at any point" has meaning. We
can have "MAY...at any point" or "SHOULD...at every point." The latter, however,
sounds pretty heavy: is it what you meant?

> * 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]

Good that the registry has now been set up, and yes we should now reference it.

However, we cannot demand the value zero like this.

Best,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 Dec 2017 21:24:49 -0000

OK Dave, that text needs clearing up.

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

The norm is that a document describes what you have to do to conform to the
specification, and if there is prior deployment, it describes how interworking
works for backward compatibility.

So, Section 3 describes how to conform to this spec, and Section 4 describes
backward compatibility.

We can add some clarity as follows:

At the top Section 3...
OLD
   An SFC-aware node wishing to send metadata without a data packet:
NEW
   An SFC-aware node wishing to send metadata without a data packet
   (i.e., a node that conforms to this specification):
END

Halfway down Section 3
OLD
   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.
NEW
   A transit node (SFF, SFI, or Classifier) that conforms to this specification
   and that receives 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.  Processing for
   nodes that do not support "Next Protocol" set to "None" is described
   in Section 4.
END

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 Dec 2017 22:58:40 -0000

Hi Greg,

Thanks for this.

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

Yes. The discussion of SFC OAM has come on a bit recently.

> 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, authors consider
> encapsulating iOAM data after the SFC NSH using iOAM protcol type. And
> what is 'must' in this statement - normative or mere observation?

Yeah, maybe I was sloppy in my use of "metadata". However I think I stand by what is written maybe with s/must be/is/. That is, it is neither protocol header in the SFC layer nor payload, so it is "metadata".

Yes, I think iOAM is metadata. But obviously not NSH metadata.

I don't want to get into the debate (here) about the problems of using Next Protocol == iOAM when there is data present, or the preferable action of defining a T2 metadata TLV to contain the iOAM stuff, or anything else about iOAM.

Anyway, the way we should cover this is...

"If OAM information is carried in packets that also include payload data, that information may be carried in metadata between the NSH and the payload."

> "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
> 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.

Why debate today that which can usefully be put off until tomorrow?

Now, I know that this document was not adopted by the WG, but it is a bit harsh to cite another individual draft as reasoning for changing this document.

As we have known for some time, we have a multiplicity of ways to indicate the presence of OAM, and no clarity in the WG. draft-wang-sfc-multi-layer-oam has a neat solution to reducing the number of mechanisms by requiring that two are used at once :-)

But it is not my intention to define how OAM is performed in an NSH network, just to show how it might be performed.

What if we soften the language by adding a paragraph such as:

"Mechanisms for providing active OAM [RFC7799] in an SFC network have been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is not intended to define another mechanism for active OAM, but does illustrate a further option for discussion by the working group."

Cheers,
Adrian

---

From: <[email-masked]>
Date: Fri, 8 Dec 2017 07:35:22 +0000

Hi Adrian, 

Thank you for the follow-up. Below to clarifications from my side:
- by metadata fields I meant "Context Header(s)".
- You said: "My understanding of metadata is that it is consumed only at SFIs". Actually context headers can be added/striped/modified by other elements. Please refer to this table:

   +-----------+-----------------------+-------+---------------+-------+
   |           | Insert, remove, or    |Forward| Update        |Service|
   |           | replace the NSH       |the NSH| the NSH       |policy |
   |           |                       |Packets|               |sel.   |
   |Component  +-------+-------+-------+       +-------+-------+       |
   |           |       |       |       |       |Dec.   |Update |       |
   |           |Insert |Remove |Replace|       |Service|Context|       |
   |           |       |       |       |       |Index  |Header |       |
   +-----------+-------+-------+-------+-------+-------+-------+-------+
   |           |  +    |       |   +   |       |       |   +   |       |
   |Classifier |       |       |       |       |       |       |       |
   +-----------+-------+-------+-------+-------+-------+-------+-------+
   |Service    |       |   +   |       |   +   |       |       |       |
   |Function   |       |       |       |       |       |       |       |
   |Forwarder  |       |       |       |       |       |       |       |
   |(SFF)      |       |       |       |       |       |       |       |
   +-----------+-------+-------+-------+-------+-------+-------+-------+
   |Service    |       |       |       |       |   +   |   +   |   +   |
   |Function   |       |       |       |       |       |       |       |
   |(SF)       |       |       |       |       |       |       |       |
   +-----------+-------+-------+-------+-------+-------+-------+-------+
   |           |  +    |   +   |       |       |   +   |   +   |       |
   |SFC Proxy  |       |       |       |       |       |       |       |
   +-----------+-------+-------+-------+-------+-------+-------+-------+

Cheers,
Med

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[email-masked]]
> Envoyé : jeudi 7 décembre 2017 19:37
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : 'Joel M. Halpern'; [email-masked]
> Objet : RE: [sfc] WG Last Call for draft-farrel-sfc-convent
> 
> Hey Med,
> 
> Thanks for the review.
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 15 Dec 2017 18:49:19 -0600

Hi Adrian,
thank you for your kind consideration of my comments and thoughtful
responses. Please find my follow-up notes in-line tagged GIM>>.

Happy holidays and the best wishes to all!

Regards,
Greg

On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel <[email-masked]> wrote:

> Yeah, maybe I was sloppy in my use of "metadata". However I think I stand
> by what is written maybe with s/must be/is/. That is, it is neither
> protocol header in the SFC layer nor payload, so it is "metadata".
>
GIM>> True, RFC 7665 does not define where the metadata may be placed but
in the very Introduction to NSH SFC stated that the metadata is part of NSH:

   The NSH is composed of the following elements:
   1.  Service Function Path identification.
   2.  Indication of location within a Service Function Path.
   3.  Optional, per packet metadata (fixed length or variable).

> I don't want to get into the debate (here) about the problems of using
> Next Protocol == iOAM when there is data present, or the preferable action
> of defining a T2 metadata TLV to contain the iOAM stuff, or anything else
> about iOAM.
>
> "If OAM information is carried in packets that also include payload data,
> that information may be carried in metadata between the NSH and the
> payload."
>
GIM>> As noted, the metadata is one of the elements of NSH and thus cannot
be outside of it.

> Now, I know that this document was not adopted by the WG, but it is a bit
> harsh to cite another individual draft as reasoning for changing this
> document.
>
> As we have known for some time, we have a multiplicity of ways to indicate
> the presence of OAM, and no clarity in the WG.
> draft-wang-sfc-multi-layer-oam has a neat solution to reducing the number
> of mechanisms by requiring that two are used at once :-)
>
> But it is not my intention to define how OAM is performed in an NSH
> network, just to show how it might be performed.
>
> "Mechanisms for providing active OAM [RFC7799] in an SFC network have been
> proposed [I-D.wang-sfc-multi-layer-oam]. This use case is not intended to
> define another mechanism for active OAM, but does illustrate a further
> option for discussion by the working group."
>
GIM>> I fully agree with the proposed text.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Dec 2017 19:57:18 -0500

In order that we know where we stand on this document, let me ask you 
two opposite questions:

1) There are clearly some aspects of this document with which you are 
unhappy.  With the change noted in the final portion of the email below, 
can you live with the rest of the document as is?

2) Conversely, can you suggest specific text changes that would help 
address your concerns?

And to round out the set, are there other people in the working group 
who share Greg's concern?  If so, can you please comment, preferably 
with a text suggestion that would address what drives your view of the 
issue?

Yours,
Joel

On 12/15/17 7:49 PM, Greg Mirsky wrote:
> On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Greg,
> 
>     Thanks for this.
> 
>     Yeah, maybe I was sloppy in my use of "metadata". However I think I
>     stand by what is written maybe with s/must be/is/. That is, it is
>     neither protocol header in the SFC layer nor payload, so it is
>     "metadata".
> 
> GIM>> True, RFC 7665 does not define where the metadata may be placed 
> but in the very Introduction to NSH SFC stated that the metadata is part 
> of NSH:
> 
> The NSH is composed of the following elements: 1. Service Function Path 
> identification. 2. Indication of location within a Service Function 
> Path. 3. Optional, per packet metadata (fixed length or variable).
> 
> 
> 
>     I don't want to get into the debate (here) about the problems of
>     using Next Protocol == iOAM when there is data present, or the
>     preferable action of defining a T2 metadata TLV to contain the iOAM
>     stuff, or anything else about iOAM.
> 
>     data, that information may be carried in metadata between the NSH
>     and the payload."
> 
> GIM>> As noted, the metadata is one of the elements of NSH and thus 
> cannot be outside of it.
> 
> 
>     Now, I know that this document was not adopted by the WG, but it is
>     a bit harsh to cite another individual draft as reasoning for
>     changing this document.
> 
>     As we have known for some time, we have a multiplicity of ways to
>     indicate the presence of OAM, and no clarity in the WG.
>     draft-wang-sfc-multi-layer-oam has a neat solution to reducing the
>     number of mechanisms by requiring that two are used at once :-)
> 
>     "Mechanisms for providing active OAM [RFC7799] in an SFC network
>     have been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is
>     not intended to define another mechanism for active OAM, but does
>     illustrate a further option for discussion by the working group."
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 15 Dec 2017 19:16:39 -0600

Hi Joel,
thank you for formulating clear questions to clarify my view on the
document.
My remaining concern is with the proposed new text:
    "If OAM information is carried in packets that also include payload
    data, that information may be carried in metadata between the NSH
    and the payload."
I can suggest to omit reference to metadata in this sentence, like "that
information may be carried between the NSH and the payload". But that would
effectively open the door for solutions similar to the one proposed in
draft-ooamdt-rtgwg-ooam-header.
And it was strongly opposed by some participants of SFC WG for exactly
enabling such solution.

Perhaps if no one else speaks up, we'll have rough consensus to move the
document forward as suggested by WG Chairs.

Regards,
Greg

On Fri, Dec 15, 2017 at 6:57 PM, Joel M. Halpern <[email-masked]>
wrote:

> In order that we know where we stand on this document, let me ask you two
> opposite questions:
>
> And to round out the set, are there other people in the working group who
> share Greg's concern?  If so, can you please comment, preferably with a
> text suggestion that would address what drives your view of the issue?
>
> Yours,
> Joel
>
>> identification. 2. Indication of location within a Service Function Path.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 16 Dec 2017 22:04:55 -0000

OK, I think we are close.
 
Rather than spending time defining what is and what is not "metadata" (whether in the SFC context or more generally), we can leverage your formulation. 
 
If we agree that OAM information might be carried between the NSH and the payload, then we can have...
OLD
    If OAM information is carried in packets that also include payload
    data, that information may be carried in metadata between the NSH
    and the payload.
NEW
    If OAM information is carried in packets that also include payload
    data, that information might be carried between the NSH and the
    payload.
END
 
I see no reason to debate whether this OAM information is to be called metadata or not, and so we can close the final issue from your review.
 
BTW, I understand your concern that this might open up the field for doing things that there is not support to do. But I don't think this section is providing more than commentary on this point. Furthermore, if we were to attempt to be proscriptive in this document, we would need a wider and probably more fraught debate which would not sit well with the season of goodwill that is Hanukkah.
 
Cheers,
Adrian

From: Greg Mirsky [mailto:[email-masked]] 
Sent: 16 December 2017 01:17
To: Joel M. Halpern
Cc: Adrian Farrel; Service Function Chaining IETF list
Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent
 
Hi Joel,
thank you for formulating clear questions to clarify my view on the document. 
My remaining concern is with the proposed new text:
    "If OAM information is carried in packets that also include payload
    data, that information may be carried in metadata between the NSH
    and the payload."
I can suggest to omit reference to metadata in this sentence, like "that information may be carried between the NSH and the payload". But that would effectively open the door for solutions similar to the one proposed in draft-ooamdt-rtgwg-ooam-header. And it was strongly opposed by some participants of SFC WG for exactly enabling such solution.
 
Perhaps if no one else speaks up, we'll have rough consensus to move the document forward as suggested by WG Chairs.
 
Regards,
Greg
 
On Fri, Dec 15, 2017 at 6:57 PM, Joel M. Halpern <[email-masked]> wrote:
In order that we know where we stand on this document, let me ask you two opposite questions:

1) There are clearly some aspects of this document with which you are unhappy.  With the change noted in the final portion of the email below, can you live with the rest of the document as is?

2) Conversely, can you suggest specific text changes that would help address your concerns?

And to round out the set, are there other people in the working group who share Greg's concern?  If so, can you please comment, preferably with a text suggestion that would address what drives your view of the issue?

Yours,
Joel

On 12/15/17 7:49 PM, Greg Mirsky wrote:
Hi Adrian,
thank you for your kind consideration of my comments and thoughtful responses. Please find my follow-up notes in-line tagged GIM>>.

Regards,
Greg
On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:

    Hi Greg,

    Thanks for this.

GIM>> True, RFC 7665 does not define where the metadata may be placed but in the very Introduction to NSH SFC stated that the metadata is part of NSH:

The NSH is composed of the following elements: 1. Service Function Path identification. 2. Indication of location within a Service Function Path. 3. Optional, per packet metadata (fixed length or variable).

GIM>> As noted, the metadata is one of the elements of NSH and thus cannot be outside of it.

    Cheers,
    Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 16 Dec 2017 16:44:37 -0600

Hi Adrian,
thank you for your thoughtful consideration and patience. I agree with the
proposed new text.

Regards,
Greg

On Sat, Dec 16, 2017 at 4:04 PM, Adrian Farrel <[email-masked]> wrote:

> Rather than spending time defining what is and what is not "metadata"
> (whether in the SFC context or more generally), we can leverage your
> formulation.
>
>
>
> I see no reason to debate whether this OAM information is to be called
> metadata or not, and so we can close the final issue from your review.
>
>
>
> BTW, I understand your concern that this might open up the field for doing
> things that there is not support to do. But I don't think this section is
> providing more than commentary on this point. Furthermore, if we were to
> attempt to be proscriptive in this document, we would need a wider and
> probably more fraught debate which would not sit well with the season of
> goodwill that is Hanukkah.
>
>
>
> Cheers,
>
> Adrian
>
>
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* 16 December 2017 01:17
> *To:* Joel M. Halpern
> *Cc:* Adrian Farrel; Service Function Chaining IETF list
> *Subject:* Re: [sfc] WG Last Call for draft-farrel-sfc-convent
>
>
>
> Hi Joel,
>
> draft-ooamdt-rtgwg-ooam-header. And it was strongly opposed by some
> participants of SFC WG for exactly enabling such solution.
>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 Dec 2017 13:27:12 -0500

This WG Last Call is completed.

With the changes that were discussed and have been applied (thank you 
Adrian) the document is approved.

We will be getting a shepherd and shepherd writeup so as to get this in 
front of our Area Director when she returns from the holidays.

Thank you to all who helped with this.

Yours,
Joel and Jim

On 11/29/17 4:13 PM, Joel M. Halpern wrote:
> 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)
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>