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

[Tal Mizrahi <[e-mail]>]

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) <
[e-mail]> wrote:

> Hello, Greg,
>
> Please see inline.
>
> On Jun 11, 2019, at 12:23 AM, [e-mail] 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,
>
> 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>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:
>
>
> 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 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.
>
> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
>
> This comment is not answering my question. The general idea is clear
> without this document. The specific idea is not explained in this document.
>
> 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,
>
> 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?
>
>    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.
>
> 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.
>
> 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] <[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 [e-mail]<mailto:[e-mail] <[e-mail]>>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>
>
>
>