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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 07 May 2020 04:39:52 -0700

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.

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"?

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.

4.3.  Trace Functions

"TTL" is used in various places.  Does that need to be listed in the acronyms?

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?

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"?

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?

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.

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?

Regards,
Rob

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 14 May 2020 19:05:43 +0000

Hi Robert,

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

    

<Nagendra> Thank you (

    2.  SFC Layering Model

    
<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

    
<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

<Nagendra> TTL is a well-known abbreviation as per https://www.rfc-editor.org/materials/abbrev.expansion.txt. 

    

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

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

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

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

<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