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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 06 May 2020 13:27:05 -0700

Roman Danyliw 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 1.  Per “OAM controllers are assumed to be within the same
administrative domain as the target SFC enabled domain”, is there a
circumstance where the OAM controller would be working across administrative
domains?  Can this statement be made stronger – “OAM controller MUST be within
the same administrative …”

** Section 2.  Example technologies for the underlay (i.e., IP MPLS) and link
(i.e., POS DWDM) layers are provided.  It might help readability to provide
such examples for the overlay network layer too.

** Section 3.0.  “Testing an SF may not be restricted to connectivity to the
SF, but also whether the SF is providing its intended service.  Refer to
Section 3.1.1 for a more detailed discussion.”  Section 3.1.1 appears to
discuss availability but not validation practices to ensure “the SF is
providing its intended service”.  Is providing the intended service as simple
as the service being up? Or does it include confirmation that functionally the
right service is happening?

** Section 3.4. Typo. s/and so/so/

** Section 3.5.  Per “The overlay network establishes the service plane between
the SFC components and are mostly transparent to the SFC data plane elements.”,
in what way is the overlay network not transparent?

** Section 5.1.  Per “Tools like ping and trace …” and “BFD is another tool …”,
what  specific instances of ping and trace are you referencing?  Or is this
generically saying ping = Section 6.4.1, trace = Section 6.4.4 and BFD =
Section 6.4.2?

** Section 5.1.  I initially found the contents of this table confusing.  The
paragraph introducing this table refers to “ping” and “trace” as tools. 
However, E-OAM, IPPM, etc. which are also noted in this table don’t seem easily
categories by the “tool” designation.

** Section 6.4.3.  Is there a reason that In-Situ OAM is mentioned here but not
in Section 5.1?

** Section 8.  Per “The sensitivity of the information from SFC layer raises a
need for careful security considerations”, what are these concerns?  It also
isn’t clear what information is being mentioned.

** Section 8.  (I’m not calling this a DISCUSS since this is a trivial
editorial fix but it MUST be done before publication) Per “To address the above
concerns, SFC and SF OAM may provide mechanism for:
   o  Misuse of the OAM channel for denial-of-services, …”

A crucial missing word here as in – s/provide mechanisms for:/provide
mechanisms for mitigating:/

** Section 8. Per “To address the above concerns, SFC and SF OAM may provide
mechanism for: …
   o  Leakage of OAM packets across SFC instances, and
   o  Leakage of SFC information beyond the SFC domain.”

-- the text above mentions the risk of risk of SFC evasion but this isn’t
mentioned here

-- the two bullets here seem appropriate and needed OAM activities but they
don’t follow from the text above (as explicitly promised by the text “to
address the above …”)

** Section 8.  What is the different between the guidance:
-- “… SRC and SF OAM may provide mechanism to [mitigate]: … leakage of SFC
information beyond the SFC domain” -- “The documents proposing the OAM solution
for any service layer component should consider some form of message filtering
to prevent leaking any internal service layer information outside the
administrative domain”

To me they are saying the same thing, except the second item explicitly notes
message filtering.

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 13 May 2020 22:43:52 +0000

Hi Roman,

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

    

<Nagendra> One of the common suggestions from different reviewers is to avoid using normative statement in this document. But we can update this as below:

OLD:
OAM controllers are assumed to be within the same administrative
   domain as the target SFC enabled domain.

NEW:
OAM controllers should be within the same administrative
   domain as the target SFC enabled domain.

<Nagendra> While the underlay/link layer examples included are established and commonly seen in many deployments, I think it might be too early to include such example for the overlay (. 

<Nagendra> This is discussed in Section 3.1.1. The availability of an SF can be tested by simply checking if the SF is up and running or can forward the traffic through to apply the SF and ensure that the SF is working as desired. But this may not be a facile task and comes with its own complexity as discussed in section 3.1.1.  

<Nagendra> Fixed.

<Nagendra>I can't think of any scenario where it is not transparent. I am fine removing the term "mostly" from the sentence.

<Nagendra> The specifics of the tool vary depending on the type of the network. For example, IP Ping is used when the network is IP, while LSP Ping is used for MPLS network.

<Nagendra>This is a broad classification of different OAM tools. AFAIR, other RFCs has referred E-OAM as tools.

<Nagendra> Section 5.1 and the table listed the tools that are available during the time of this writing. I am not aware of any draft that suggests the use of In-Situ OAM for connectivity or continuity check. So I am not sure if it we can include In-Situ OAM in the table as a tool available for these purpose. If there is any suggestion, please let us know.

<Nagendra> The subsequent paragraph explains that sensitive information and the concerns associated with the same.

    
<Nagendra> Yes, Good catch (. Fixed it.

    
<Nagendra> SFC evasion is a byproduct of the internal data leak. By addressing the leak, we can avoid an attacker using the leaked data to identify the holes to bypass the SFC. So, I think it may not be a direct concern to be listed here in this section.

<Nagendra> I am not sure I understand this query. Can you please help clarity?.

    
<Nagendra> The former statement is a consideration to address the security concern while the latter is more of a guidance for the future documents that are proposing the solution.

Once again thanks a lot for the great comments.

Thanks,
Nagendra