Re: [sfc] Benjamin Kaduk's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

Hi Benjamin,

Thank you for the comments. Please see inline for more response.

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-sfc-oam-framework-13: No Objection
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Section 2
    
    I'm not sure that I understand why a node in the underlay network (the
    "VM2" one) doesn't line up with a node in the link layer, in Figure 1.
   
<Nagendra>Am I assuming right that the question is about the misalignment between the nodes on Link layer and underlay layer?. If so, it was a typo and we fixed it. If I misunderstood the question, please let me know.

    Section 3
    
           classifiers, controllers, other service nodes).  Testing an SF
           may not be restricted to connectivity to the SF, but also whether
    
    nit(?) perhaps "may be more expansive than just checking connectivity to
    the SF", to avoid questions about what the "not" binds to.
  
<Nagendra> Yes. Your suggested text seems to make it easy to parse the statement. Please check the below text:

OLD:
Testing an SF
       may not be restricted to connectivity to the SF, but also whether
       the SF is providing its intended service.

NEW:
Testing an SF
       may be more expansive than just checking connectivity to the SF
       such as checking if the SF is providing its intended service.

       3.  Classifier component: OAM functions applicable at this component
           includes testing the validity of the classification rules and
           detecting any incoherence among the rules installed in different
           classifiers.
    
    It seems important to include both positive and negative tests of
    classification functionality (i.e., that traffic that should not match
    in fact does not match).  Section 3.3 might be a good place to mention
    this.
    
<Nagendra> The below text in Section 3.3 is intended to cover such misclassification:

" The SFC OAM must be able to validate the classification
   rules by assessing whether a flow is appropriately mapped to the
   relevant SFC."

If the above is not clear, we can update the same as:

NEW:
The SFC OAM must be able to validate the classification
   rules by assessing whether a flow is appropriately mapped to the
   relevant SFC and detect any misclassification.

    Section 3.1.1
    
       service function is available?.  On one end of the spectrum, one
       might argue that an SF is sufficiently available if the service node
       (physical or virtual) hosting the SF is available and is functional.
       On the other end of the spectrum, one might argue that the SF's
       availability can only be concluded if the packet, after passing
    
    I agree with the other reviewers that the first "end" of the spectrum
    seems surprising.
    
       firewall).  The cost of this approach is that the OAM mechanism for
       some SF will need to be continuously modified in order to "keep up"
       with new functionality being introduced: lack of extendibility.
   
    nit: the grammar doesn't seem right around "lack of extendibility"
    (also, is "extendibility" preferred or "extensibility"?).

 <Nagendra> We have this changed to extensibility.

       The SF availability can be performed using a generalized approach
       (i.e., an adequate granularity to provide a basic SF service).  More
    
    nit: I think it's an availability *check* that can be performed.
 
<Nagendra> Good catch (. Fixed it.

    Section 3.2.2
    
    Mandating the ability to measure every arbitrary segment of SFs within
    an SFC seems like it might be over-constraining.

<Nagendra>This is not a normative statement but intended to detect and isolate performance issue within the SFC.

    Section 4
    
       to perform OAM functionality at different layers.  In order to apply
       such OAM functions at the service layer, they need to be enhanced to
       operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in
       multiple SFCs.
    
    I don't understand what "operate a single SFF to multiple SFs/SFFs"
    means.
 
<Nagendra> We got similar comments from other reviewers highlighting the ambiguity. We changed it as below:

OLD:
In order to apply
   such OAM functions at the service layer, they need to be enhanced to
   operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in
   multiple SFCs.

NEW:
In order to apply such OAM functions at the service layer, they need to be enhanced 
to operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs.

    Section 4.1
    
       o  Verify any packet re-ordering and corruption.
    
    nit: this wording doesn't really make sense.  Do we want to verify the
    absence of such things, or that it is within configured tolerances, or
    something else?  Just noting any occurrences and verifying that the
    noted occurrences are as noted doesn't seem useful...
   
<Nagendra> We changed this as "detect" instead of "verify".

       o  Verify the policy of an SFC or SF.
    
    nit: similarly, is this to verify the configuration, or to verify that
    operation matches the expected configuration?
    
<Nagendra> This section is about connectivity function and so it is intended to verify the operation based on the configuration.

    Section 4.2
    
       Continuity is a model where OAM messages are sent periodically to
       validate or verify the reachability to a given SF within an SFC or
    
    nit: while it's "connectivity to", I think it's "reachability of".
    
<Nagendra> Changed it.

       o  Notifying the detected failures to other OAM functions or
          applications to take appropriate action.
    
    nit: the subject of a notification is the entity receiving notification,
    not the content of the notification.  So "notifying other OAM functions
    or applications of the detected failures so they can take appropriate
    action", or "Sending notifications of the detected failures to other
    [...]".
    
<Nagendra> The former one looks more appropriate. 

    Section 4.4
    
       delay [RFC7679] is important.  In order to measure one-way delay,
       time synchronization MUST be supported by means such as NTP, PTP,
       GPS, etc.
    
    I think (informational) references are in order for these.  (PTP is not
    listed as "well-known" at
    https://www.rfc-editor.org/materials/abbrev.expansion.txt , though the
    other two are.)
    
<Nagendra> Based on my understanding on the above cited document, I expanded PTP and left the other two as it is. Let me know if the other two should be expanded.

       One-way delay variation [RFC3393] could also be calculated by sending
       OAM packets and measuring the jitter between the packets passing
       through an SFC.
    
    Looking at jitter between (measurement) packets to ascertain delay
    variation seems to require foreknowledge of the (e.g., periodic) pacing
    of the initial packet transmission.  If, on the other hand, the idea is
    to look at the jitter across the measured delay of each packet, then
    that works fine (but that's not what the current text says).
    
<Nagendra> Agreed. The measurement may need time synchronization and additional negotiation such as probe pace etc. But I think that this should be clarified in the solution documents.

       o  Ability to measure the packet loss [RFC7680] within an SF or an
          SFP bound to a given SFC.
    
    nit(?): packet loss "within an SF" (as opposed to between two SFs) is
    not something I would have expected to need measuring, on first thought.
    Though on further reflection it is less surprising; still, I wanted to
    check that this is indeed as intended.
    
<Nagendra> The ability to measure packet loss within an SFP helps detect such loss while the ability to measure packet loss within an SF helps isolate the issue. 

    Section 5.2
    
       As shown in Table 3, there are no standards-based tools available for
       the verification of SFs and SFCs.
    
    Some note about "at the time of this writing" or similar seems advised;
    otherwise this statement is unlikely to age well.
    
<Nagendra> That make sense. Please find the updated text below:

OLD:
As shown in Table 3, there are no standards-based tools available for
   the verification of SFs and SFCs.

NEW:
As shown in Table 3, there are no standards-based tools available at the 
time of this writing for the verification of SFs and SFCs.

    Section 6.2
    
       An SFF may choose not to forward the OAM packet to an SF if the SF
       does not support OAM or if the policy does not allow to forward OAM
       packet to an SF.  The SFF may choose to skip the SF, modify the
       header and forward to next SFC node in the chain.  It should be noted
       that skipping an SF might have implication on some OAM functions
       (e.g. the delay measurement may not be accurate).  The method by
    
    This behavior was initially surprising to me, and "might have
    implication on" feels like weaker text than is merited.  While I can
    perhaps imagine that not forwarding an OAM packet to an SF that will
    choke on it instead of doing something useful, it seems like it's rather
    divergent from the OAM expectations to silently bypass a given SF and is
    quite likely to affect the accuracy of the resulting OAM results.
    
<Nagendra> Forwarding the OAM packet to an SF that does not support (or the policy config does not allow) OAM may result in packet drops depending on the type of SF. For example, a FW may drop the OAM packet while other SF such as pkt-capture-sf may simply pass it through. It may be difficult to differentiate if the drop is due to the lack of feature support or some forwarding/processing issue. Such inaccuracy on the OAM function is highlighted in this section.

       process OAM packets is outside the scope of this document.  It could
       be a configuration parameter instructed by the controller or it can
       be done by dynamic negotiation between the SF and SFF.
    
    (Is there an existing mechanism for dynamic negotation between SF and
    SFF?)
    
<Nagendra>Not that I know of. If it vitiates the section or sentence, we can remove it.

    Section 6.3
    
       As described in Section 4, there are different OAM functions that may
       require different OAM solutions.  While the presence of the OAM
       marker in the overlay header (e.g., O bit in the NSH header)
       indicates it as OAM packet, it is not sufficient to indicate what OAM
       function the packet is intended for.  The Next Protocol field in NSH
       header may be used to indicate what OAM function is intended to or
       what toolset is used.
    
    Elsewhere in the document we make reference to what would be required of
    a non-NSH encapsulation header; is it appropriate to also do so here?
    
<Nagendra> Does the below modified text looks better?:

OLD:
The Next Protocol field in NSH
   header may be used to indicate what OAM function is intended to or
   what toolset is used.

NEW:
The Next Protocol field in NSH
   header may be used to indicate what OAM function is intended to or
   what toolset is used. Any other overlay encapsulations used at the service 
layer must have a similar way to indicate the intended OAM function.

    Section 6.4.2
    
       BFD or S-BFD could be leveraged to perform continuity function for SF
       or SFC.  An initiator could generate a BFD control packet and set the
       "Your Discriminator" value as last SFF in the control packet.  Upon
    
    nit: I think this "your discriminator" would be the address or
    identifier of the last SFF, not just "the last SFF" itself, right?
    Or be set "to indicate" the last SFF, or similar.
    (Also occurs a few sentences later.)
    
<Nagendra> Yes, good catch (. Modified the same in the relevant sentences.

       with relevant DIAG code.  The TTL field in the NSH header could be
       used to perform partial SFC availability.  For example, the initiator
    
    nit: availability checks/checking
    
<Nagendra> Fixed.

    Section 6.4.4
    
       [I-D.penno-sfc-trace] defines a protocol that checks for path
       liveliness and traces the service hops in any SFP.  Section 3 of
       [I-D.penno-sfc-trace] defines the SFC trace packet format while
       Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF
       and SFF respectively.  While [I-D.penno-sfc-trace] has expired, the
       proposal is implemented in Open Daylight and available.
    
    Why is draft-penno-sfc-trace not progressing towards publication?
    
<Nagendra> I will let the authors of penno-sfc-trace to comment on the plans to move it towards publication.

    Section 7
    
    I think this table really needs more lead-in to what it's communicating.
    
       As depicted in Table 4, information and data models are needed for
       configuration, manageability and orchestration for SFC.  With
    
    I don't see where that is actually indicated by the table.
    
<Nagendra> The data models required for config/orchestration of any SFC elements (such as classifier/SF/SFF) is not available today. We can clarify this in the section. Please see if the below text clarifies:

OLD:
As depicted in Table 4, information and data models are needed for
   configuration, manageability and orchestration for SFC.

NEW:
While the NETCONF capabilities are readily available as depicted in Table 4, the information and data models are needed for
   configuration, manageability and orchestration for SFC.

    Section 8
    
    OAM information (though most usefully as summary statistics), if leaked,
    could also be used by an attacker to gauge the efficacy of an ongoing
    attack.
    
<Nagendra> Section 8 already defines the below:

"The documents proposing the OAM solution for any service layer components should consider some form of message filtering to prevent leaking any internal service layer information outside the administrative domain."

I believe this covers the point you raised. Please let us know if it doesn’t. 

       Any security consideration defined in [RFC7665] and [RFC8300] are
       applicable for this document.
    
    The rest of the document implies that NSH is not mandatory, so I'd
    suggest rewording this reference to clarify what from RFC 8300 is (or is
    not) applicable to the whole of the document.
    
<Nagendra> While not mandatory, NSH is one of the overlay headers that could be used for encapsulating the OAM packets. So, any security considerations defined in RFC8300 is applicable when the OAM solutions are using NSH as overlay header. 

       The mapping and the rules information at the classifier component may
       reveal the traffic rules and the traffic mapped to the SFC.  The SFC
       information collected at an SFC component may reveal the SF
       associated within each chain and this information together with
    
    nit: s/the SF/the SFs/
    
<Nagendra> Fixed.

       To address the above concerns, SFC and SF OAM may provide mechanism
       for:
    
    (1) The crucial missing word that Roman notes is indeed crucial!
    (2) Can we say something stronger than "may"?
    
<Nagendra> This is changed to "should" based on the SecDir comments.

       The documents proposing the OAM solution for any service layer
       components should consider some form of message filtering to prevent
       leaking any internal service layer information outside the
       administrative domain.
    
    "should consider" is fairly weak guidance; would "should provide" be
    appropriate?
    
<Nagendra> Changed the same as "should provide".

    Also, is it worth mentioning that this filtering would include dropping
    OAM-marked messages from outside the domain (at least by default)?
    
<Nagendra> I checked the section and didn’t see any specifics about incoming OAM packets. Does the below text clarify?

OLD:
Rate-limiting may be applied at the SFF or the SF

NEW:
Rate-limiting may be applied at the Classifier, SFF or the SF

    Section 12.1
    
    The only citation to RFC 8300 that appears to require a normative
    reference is the bit in the security considerations that I noted was
    unclear about its scope of applicability.
    
<Nagendra> We updated the document to avoid using normative statements. Let me check with my co-authors to see if we should move all the references as Informative.

    Section 12.2
    
    RFC 6291 is a BCP, so we should probably cite it as such.  Also, given
    its content, perhaps it ought to be normative?
    
<Nagendra> Same as above.

Once again, thanks a lot for the great comments. 

Thanks,
Nagendra