Subject: Re: [sfc] Adopting draft-mirsky-sfc-pmamm

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 10 Jun 2019 05:10:11 +0000

Joel, Jim,

I reflected on this adoption call. In the end, I oppose adopting this draft as a working group document at this point.

After all consideration, my evaluation is that, at best, it is very premature.

Here’s some of the technical reasons for this:

1. Fundamental mis-assumptions.

1.1.

The whole basis of this document is using a “marking” method as a passive PM method. This is the only sentence in the Abstract:

   This document describes how the alternate marking method be used as
   the passive performance measurement method in a Service Function
   Chaining (SFC) domain.

However, the definition of a passive method from RFC 7799 is:

https://tools.ietf.org/html/rfc7799#section-3.6
   o  based solely on observations of an undisturbed and unmodified
      packet stream of interest (in other words, the method of
      measurement MUST NOT add, change, or remove packets or fields or
      change field values anywhere along the path).

This definition says MUST NOT change field values.

I understand the document says:
   alternate marking method in SFC layer can be viewed as a real example
   of passive performance measurement method.

However, that is not saying “it is a passive method because of this thorough analysis”.

I also understand that RFC 8321 gives guidance of when an alternate-marking method can be considered Hybrid vs. Passive.

I remember because I was Document Shepherd on that I-D to become RFC 8321.

However, the SFC NSH can be encapsulated in a number of transport encapsulation protocols. There is no analysis to explain how the changing of this field value will not result in a different forwarding (e.g., path, treatment) decision.

For example, there’s an MPLS SFC NSH encapsulation just published as RFC, and here this document attempts to define a bit in the first nibble. RFC 8300 carefully reserved version numbers to prevent ECMP treatment. Here, my point is no to move the bit around, but to exemplify how there’s been lack of captured thought about this proposal and approach.

1.2.

There’s been no discussion about whether this specific solution is what SFC needs for Passive OAM, or of the risks of this modifying forwarding. And weather the NSH Base Header is the best place for these measurements.

2. Solution looking for a problem.

This draft defines a solution, but it really does not indicate the scope or extend of the problem being solved. It does not explain how this specific solution fits in the potential constellation of OAM solutions for SFC.

And as such, it is impossible to compare it against other potential solutions, or to evaluate or understand how it fits in the overall OAM Framework.

Which exact function of OAM is this solving, and given the graph-nature of SFC, is this too simplistic of a solution for Performance Measurement, where other hybrid solutions can provide a large superset of this functionality?

This is compounded by one additional issue:

There seems to be a tendency of, without explanation, extrapolating RFCs and solutions into all possible protocols, regardless of their need.

For example, after RFC 7110, there were all kinds of specified-return-paths documents for many protocols — even for things that did not make full sense like for SFC. I would cautious us to develop standards based on needs.

And equally important, to understand the overall landscape of Performance Measurement before pushing too localized solutions.

3. Grossly underdefined and underspecified operations.

3.1.

The Theory of Operation in Section 4 does not really explain the role of any node (headend, tailed, midpoint) or (SF, SFF, Classifier). Which nodes can/must mark/read/change, etc. Sections 4.1, 4.2, 4.2 explains details of the Alternate Marking method, but not the SFC applicability or usage.

3.2.

What is the default value for the bit?

3.3.

The document says it creates sub-flows within SFC:

   Using the marking method a component of the SFC creates distinct sub-
   flows in the particular service traffic over SFC.

How does this interact with Flow concepts in SFC?

4. Effectively null considerations to security.

The security considerations reads:

   This document lists the OAM requirement for SFC domain and does not
   raise any security concerns or issues in addition to ones common to
   networking and SFC.

It is unclear if that is a copy/paste from another document, or what it really means.

5. Minor issues

The NSH [RFC 8300] does not have “R” bits. It has “U” bits.

Thanks,

Carlos.

On May 24, 2019, at 2:17 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

This email starts the adoption call for draft-mirsky-sfc-pmamm (https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/).

Please speak up if you support or oppose adopting this document as a working group document.  Please provide reasons for that view.
Silence will not be considered consent.

The adoption call will end CoB 10 June 2019.

Yours,
Joel (and Jim

On 5/20/19 1:58 PM, Greg Mirsky wrote:
Dear Joel and Jim,
authors ofdraft-mirsky-sfc-pmamm believe that the draft, that defines how the Alternate Marking (RFC 8321) technique can be used in SFC NSH, is stable, and ready for the working group adoption. Much appreciate your consideration to start the WG AP.
Best regards,
Greg

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc