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

[<[e-mail]>]

Dear Carlos,


thank you for your review and comments. Please find my responses in-line tagged GIM>>. Attached are the updated version and the diff.








Regards,


Greg Mirsky









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. 
GIM>> I agree that from the classification of the performance measurement methods the AltMark method belongs to Hybrid class. Thus I accept your comments and propose two updates in Abstract:
OLD TEXT:
 This document describes how the alternate marking method be used as
 the passive performance measurement method in a Service Function
 Chaining (SFC) domain.
NEW TEXT:
 This document describes how the alternate marking method can be used
 as the efficient performance measurement method taking advandage of
 the actual data flows in a Service Function Chaining (SFC) domain. 
Introduction:
OLD TEXT:
 [RFC8321] describes the passive performance measurement method, which can be
 used to measure packet loss, latency, and jitter on live traffic.
NEW TEXT:
 [RFC8321] describes the hybrid performance measurement method, which can be
 used to measure packet loss, latency, and jitter on live traffic. 
and Section 3:
OLD TEXT:
 Because the setting of the field to any value does not affect
 forwarding and/or quality of service treatment of a packet, the
 alternate marking method in SFC layer can be viewed as a real example
 of passive performance measurement method.
NEW TEXT:
 Though the setting of the field to any value likely not affect
 forwarding and/or quality of service treatment of a packet, the
 alternate marking method in SFC layer it is characterized as an
 example of hybrid performance measurement method according to
 [RFC7799]. 
 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.
GIM>> I cannot find a technical foundation for your concern. The proposed M field, as well as already allocated in RFC 8300 O field have no impact on possible ECMP treatment of NSH. The fact is that devices that use DPI after the MPLS stack are acting only on 0x04 and 0x6 values. Because the value 01b is reserved for the V field, an NSH cannot be taken for IPv4 or IPv6 header with any values of O and M fields. If it is not clear from Section 2.2 in RFC 8300, we can add text in the further version.
 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.
 GIM>> The draft was presented at the meetings and received a reasonable amount of comments. Could you point to the text in the draft that proposes a change in forwarding? Also, I'd indicate that the measurements are performed at the node that acts on the M field and that the results are not exported in the data packet that triggered the measurement but stored at the node. A possible method to export the results is outside the scope of the draft.


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.
 GIM>> I don't see how this is relevant to this WG AP.

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. 
GIM>> The general idea is reflected in 
 Using the marking method a component of the SFC creates distinct sub-
 flows in the particular service traffic over SFC. Each sub-flow
 consists of consecutive blocks that are unambiguously recognizable by
 a monitoring point at any component of the SFC and can be measured to
 calculate packet loss and/or packet delay metrics.
Also, Section 4.2 describes how AMM can be used to measure the Residence Time of SFF and/or SF. Of course, we'll continue adding more details to explain examples of using AMM in SFC and welcome all contributions, suggestions. 

3.2.

What is the default value for the bit?
GIM>> By default the M flag MUST be set to 0. The added text in Section 3:
NEW TEXT
 The Mark field MUST be set to 0 at initialization of NSH and ignored on
 receiption when the method is not in use.
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?
GIM>> These sub-flows are only detected by a node that is being enabled to use AMM on the given SFC flow. As stated in Section 3,
 The Mark field MUST NOT be
 used in defining forwarding and/or quality of service treatment of an
 SFC packet. The Mark field MUST be used only for the performance
 measurement of data traffic in the SFC layer.
AMM sub-flows must not alter processing of SFC flow they are part of. 

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.
GIM>> Will expand on Security Consideration in further versions.
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.
GIM>> Thank you. Update the figure.

Thanks,

Carlos.



On May 24, 2019, at 2:17 PM, Joel M. Halpern <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/sfc