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

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

Hi Robert,

Thanks a lot for the great comments. Please see inline for the response..

    Robert Wilton 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:
    ----------------------------------------------------------------------
    
    I found this document to be pretty easy to read and understand, so thank you
    for your work in this area.
    
<Nagendra> Thank you (

    I have a few comments, that may have already been raised by other reviewers:
    
    2.  SFC Layering Model
    
       While Figure 1 depicts an example where SFs are enabled as virtual
       entities, the SFC architecture does not make any assumptions on how
       the SFC data plane elements are deployed.  The SFC architecture is
       flexible and accommodates physical or virtual entity deployment.  SFC
       OAM accounts for this flexibility and accordingly it is applicable
       whether SFC data plane elements are deployed directly on physical
       hardware, as one or more Virtual Machines, or any combination
       thereof.
    
    Would "SF data plane elements" be more clear than "SFC data plane elements"?
    
<Nagendra> "SF data plane elements" may give an impression that it is referring to the service function itself. Scanning through other SFC related documents, most (if not all) of the document refers it as "SFC data plane elements". 

    3.  SFC OAM Components
    
       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 was not entirely clear to me what is meant by different classifiers, so
    possibly this could be elaborated slightly.
    
<Nagendra> Section 2.2 of RFC7665 list some of the common cases with more than one classifier. The above statement is intended to verify the classification policy on different such classifiers. Does the below text looks better?

OLD:
.  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.

New:
.  Classifier component: OAM functions applicable at this component
           includes testing the validity of the classification rules and
           detecting any misclassification or incoherence among the rules 
            installed when more than one classifier is used as explained 
            in section 2.2 of [RFC7665].
 

    4.3.  Trace Functions
    
    "TTL" is used in various places.  Does that need to be listed in the acronyms?
    
<Nagendra> TTL is a well-known abbreviation as per https://www.rfc-editor.org/materials/abbrev.expansion.txt. 

    6.2.  OAM Packet Processing and Forwarding Semantic
    
       Upon receiving an OAM packet, SFC-aware SFs may choose to discard the
       packet if it does not support OAM functionality or if the local
       policy prevents them from processing the OAM packet.  When an SF
       supports OAM functionality, it is desirable to process the packet and
       provide an appropriate response to allow end-to-end verification.  To
       limit performance impact due to OAM, SFC-aware SFs should rate limit
       the number of OAM packets processed.
    
    Doesn't this mean that SFC is potentially altering the thing being measured? 
    Wouldn't it be better instead to rate limit the number of OAM packets that are
    being generated in the first place?

<Nagendra> Any SF may be part of SFC that originates at different classifiers. So, rate limiting at the classifier may not be appropriate as the classifier may not be aware if there is any other OAM traffic (or the rate) originated by other classifiers.  
    
    6.1.  SFC OAM Packet Marker
    
       The SFC OAM function described in Section 4 performed at the service
       layer or overlay network layer must mark the packet as an OAM packet
       so that relevant nodes can differentiate an OAM packet from data
       packets.  The base header defined in Section 2.2 of [RFC8300] assigns
       a bit to indicate OAM packets.  When NSH encapsulation is used at the
       service layer, the O bit must be set to differentiate the OAM packet.
       Any other overlay encapsulations used at the service layer must have
       a way to mark the packet as OAM packet.
    
    "must be set" => "MUST be set" & "must have a way" => "MUST have a way"?
    
<Nagendra> One of the common suggestions from different reviewers is to avoid using normative statement and so we are updating the draft to avoid using the same. Adhering to that, I think we can leave the above statements as it is.

    But I question whether these should be musts at all.  E.g. by setting an OAM
    bit you allow the intermediate functions to potentially modify their behaviour,
    making it harder to know that the thing under test isn't changing its behaviour
    because it is being tested.  E.g. could another choice be to use some reserved
    address space to simulate flows without requiring the packets to be explicitly
    marked?

<Nagendra>While your suggestion appears to be another way to differentiate the OAM packets, the use of reserved space address is not much different from the use of O bit. Even with the reserved space address, the SF with the functionality such as "treating the packet header" may still have to deviate from its functionality. The deviation is triggered based on the reserved address in this case. 

    
    7.  Manageability Considerations
    
                       Table 4: OAM Tool GAP Analysis
      +----------------+--------------+-------------+--------+-------------+
      | Layer          |Configuration |Orchestration|Topology|Notification |
      +----------------+--------------+-------------+--------+-------------+
      | Underlay N/w   |CLI, NETCONF  | CLI, NETCONF|SNMP    |SNMP, Syslog,|
      |                |              |             |        |NETCONF      |
      +----------------+--------------+-------------+--------+-------------+
      | Overlay N/w    |CLI, NETCONF  | CLI, NETCONF|SNMP    |SNMP, Syslog |
      |                |              |             |        |NETCONF      |
      +----------------+--------------+-------------+--------+-------------+
      | Classifier     | CLI, NETCONF | CLI, NETCONF| None   | None        |
      +----------------+--------------+-------------+--------+-------------+
      | SF             |CLI, NETCONF  | CLI, NETCONF| None   | None        |
      +----------------+--------------+-------------+--------+-------------+
      | SFC            |CLI, NETCONF  | CLI, NETCONF| None   | None        |
      +----------------+--------------+-------------+--------+-------------+
    
    It would probably be useful for YANG to be listed here as well under
    configuration and Orchestration.  RESTCONF or gNMI could potentially also be
    listed, although I note that this table is not intended to be exhaustive.
    
<Nagendra> Based on the comment from another reviewer, we updated the respective section as below. Does that take care of the above query?

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.

    There is also a base YANG topology model, RFC 8345, and other extensions being
    defined, at least for Overlay and Underlay networks.  Would they be appropriate
    for the topology column?
    
<Nagendra> I think so. We can update the topology column to reflect the same.

Once again, thanks a lot for the great comments.

Regards,
Nagendra