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

From: <[email-masked]>
Date: Tue, 11 Jun 2019 12:23:11 +0800 (CST)

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 16 Jun 2019 04:32:50 +0000

Hello, Greg,

Please see inline.

On Jun 11, 2019, at 12:23 AM, [email-masked]<mailto:[email-masked]> wrote:

Dear Carlos,

Regards,

Greg Mirsky

Joel, Jim,

1.1.

However, the definition of a passive method from RFC 7799 is:<https://tools.ietf.org/html/rfc7799#section-3.6>https://tools.ietf.org/html/rfc7799#section-3.6

This comment is fundamental to the document’s approach, and in my opinion, not a quick s/passive/hybrid/g word replacement. As a hybrid method it ought to rationalize the approach with existing hybrid methods.

OLD TEXT:
GIM>> I cannot find a technical foundation for your concern.

Sorry if I was not clear, I will try to be more explicit.

 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.

This is a bold statement. Do you have a survey of all devices that perform DPI and their behavior in regards to the first nibble? (Assuming you mean 0x4 and not 0x04)

 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.

Indeed, RFC 8300 tried to prevent this as possible by reserving version 1. But my point is that assigning this would need some analysis captured in the document.

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.

Greg, First, what is a “reasonable amount of comments”? Reasonable to whom? And who is making hat call? That seems like a chair responsibility and not a document author’s call.
Second, looking objectively at https://mailarchive.ietf.org/arch/search/?q=draft-mirsky-sfc-pmamm, I do not see many non-author comments.

 Could you point to the text in the draft that proposes a change in forwarding?

Greg, did I write that the draft "proposes a change in forwarding"? Please, again, refrain from mis-attributing text that I did not write or say.

I wrote “or of the risks of this modifying forwarding”, which is quite different, and my point is that the draft should prove that it doesn’t.

 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.

On the contrary; in my opinion, this concern goes to the heart of the raison d’être of the document, and the problem it is supposedly solving.

3.1.

This comment is not answering my question. The general idea is clear without this document. The specific idea is not explained in this document.

3.2.

RFC 8300 does not use the term “flow”. Therefore, a sub-flow of what? And is this using the Flow definition in Section 5 of draft-ietf-sfc-nsh-tlv-00?

Greg, I did not comment that the section needed expanding. I was asking what it means. Maybe it needs full replacing more than expanding.

I hope these responses are useful to the WG.

Best,

Carlos.

5. Minor issues

Thanks,

Carlos.

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

Yours,
Joel (and Jim

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

<draft-mirsky-sfc-pmamm-08.txt><Diff_ draft-mirsky-sfc-pmamm-07.txt - draft-mirsky-sfc-pmamm-08.txt.html>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 17 Jun 2019 07:20:24 +0300

Hi Carlos,

[As a co-author]

Thanks for the thorough review and detailed comments.
My feeling is that most of these comments can be addressed by careful
wordsmithing.

One question that I am interested to hear your response to is: do you think
that the working group should be working on alternate marking for NSH? In
my opinion this is the most interesting question when considering working
group adoption, and I am sure you have a solid opinion since you were the
shepherd of RFC 8321 and the editor of RFC 8300. Will appreciate your
opinion on this.

Cheers,
Tal.

On Sun, Jun 16, 2019 at 7:32 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Hello, Greg,
>
> Please see inline.
>
> On Jun 11, 2019, at 12:23 AM, [email-masked] wrote:
>
> 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,
>
> However, the definition of a passive method from RFC 7799 is: <https://tools.ietf.org/html/rfc7799#section-3.6>https://tools.ietf.org/html/rfc7799#section-3.6
> This comment is fundamental to the document’s approach, and in my opinion,
> not a quick s/passive/hybrid/g word replacement. As a hybrid method it
> ought to rationalize the approach with existing hybrid methods.
>
> OLD TEXT:
> This is a bold statement. Do you have a survey of all devices that perform
> DPI and their behavior in regards to the first nibble? (Assuming you mean
> 0x4 and not 0x04)
>
> Indeed, RFC 8300 tried to prevent this as possible by reserving version 1.
> But my point is that assigning this would need some analysis captured in
> the document.
>
> Greg, First, what is a “reasonable amount of comments”? Reasonable to
> whom? And who is making hat call? That seems like a chair responsibility
> and not a document author’s call.
> Second, looking objectively at
> https://mailarchive.ietf.org/arch/search/?q=draft-mirsky-sfc-pmamm, I do
> not see many non-author comments.
>
> Greg, did I write that the draft "proposes a change in forwarding"?
> Please, again, refrain from mis-attributing text that I did not write or
> say.
>
> I wrote “or of the risks of this modifying forwarding”, which is quite
> different, and my point is that the draft should prove that it doesn’t.
>
> On the contrary; in my opinion, this concern goes to the heart of
> the raison d’être of the document, and the problem it is supposedly
> solving.
>
> This comment is not answering my question. The general idea is clear
> without this document. The specific idea is not explained in this document.
>
> RFC 8300 does not use the term “flow”. Therefore, a sub-flow of what? And
> is this using the Flow definition in Section 5
> of draft-ietf-sfc-nsh-tlv-00?
>
> Greg, I did not comment that the section needed expanding. I was asking
> what it means. Maybe it needs full replacing more than expanding.
>
> On May 24, 2019, at 2:17 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked] <[email-masked]>>> wrote:
>
> sfc mailing [email-masked]<mailto:[email-masked] <[email-masked]>>https://www.ietf.org/mailman/listinfo/sfc
>
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 19 Jun 2019 13:37:28 +0000

Hi, Tal,

Thanks for the follow-up question. [As individual WG participant.]

My individual opinion is that it is the wrong question — or at the very least, the wrong timing for the question. It is tempting to ask “should the WG be working on specific point solution XYZ that exists on some other tech?” (Iterate over various values for XYZ.) My sense is that in some cases, like this one, looking at the tree will prevent one from viewing the forest.

I believe the WG should be working in a top-down comprehensive and structured way on what’s been chartered to work on, the relevances bits being:
3) OAM and Operations & Management - In order for operators to use these tools in production networks, they need Operations, Administration, and Maintenance tools, as well as management mechanisms. This includes YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs.

And see Deliverable #5.

The key, in my humble opinion, is to map out what’s needed and what’s out there in a way in which the WG participants are providing OAM functional coverage for SFCs. Does a single technology solves n problems as opposed to n technologies solving each one piece? Those are decisions the WG cannot make if focused looking at a single bit.

Alternate marking for NSH is a very specific and narrow-in-scope solution, one for which the WG has not defined a problem to be solved or explored the landscape.

I believe this needs discussion, problem definition, solution mapping, strong alignment to a framework, not wordsmithing.

Best,

Carlos.

On Jun 17, 2019, at 12:20 AM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

[As a co-author]

Thanks for the thorough review and detailed comments.
My feeling is that most of these comments can be addressed by careful wordsmithing.

One question that I am interested to hear your response to is: do you think that the working group should be working on alternate marking for NSH? In my opinion this is the most interesting question when considering working group adoption, and I am sure you have a solid opinion since you were the shepherd of RFC 8321 and the editor of RFC 8300. Will appreciate your opinion on this.

Cheers,
Tal.

On Sun, Jun 16, 2019 at 7:32 AM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hello, Greg,

Please see inline.

Dear Carlos,

Regards,

Greg Mirsky

Joel, Jim,

1.1.

OLD TEXT:

3.1.

3.2.

Best,

Carlos.

5. Minor issues

Thanks,

Carlos.

Yours,
Joel (and Jim

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