Subject: [Int-dir] Éric Vyncke's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 06 May 2020 05:24:21 -0700

Éric Vyncke 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:
----------------------------------------------------------------------

Thank you for the work put into this document. The document is easy to read;
BTW, I found that its content is more about the justifications / requirements
for an OAM system and tools descriptions than about for a framework description.

The core of the document appears to be section 6: this should probably be
reflected in the abstract and introduction

Please address the comments raised in the Internet directorate review by Carlos
Bernardos:
https://mailarchive.ietf.org/arch/msg/int-dir/TgQulH7hytGPNxdAPWcSgkTx1IM

Please find below a couple on non-blocking COMMENTs. I would really appreciate
a reply to all these COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

I would not refer to BCP 14 (RFC 8174) as this is an architectural/framework
document (informational) and not a protocol specification.

It seems that most of the described tools are about synthetic traffic. Is there
any other means to do OAM in SFC (not that I have any suggestion...)?.

-- Section 1 --
About "to be applied to packets and/or frames", for me packets are layer-3 PDUs
and frames are layer-2 PDUs. While I am not familiar with SFC, I could envision
SFC being applied to transport or application layers PDUs. So, why restricting
the use of this document to layers 2 and 3 only ?

-- Section 2 --
Is there a reason why all 'virtual links' are not mentioned in this section?
I.e., SR-IOv network, tun/tap, ...

Similar question about why limiting the example of VM and not including
containers ?

-- Section 3 --
The word "performance" is often used in the document but it is not described in
depth though: is it about the SF CPU/memory or 'client traffic' latency &
throughput ? Section 4 partially addresses my question but not completely;
also, adding forward pointers to section 4 would be nice.

-- Section 4.3 --
Please bear with my ignorance of SFC world... but, if a SF is doing proxying /
rewriting the application message, how useful is an end-to-end PMTUd check? As
there are two stitched TCP connections ?

The overall assumption of this section is that all SF are pure layer-3, leaving
the IP header intact so that ECMP & TTL checks can be done. Is it always the
case ?

Section 5.2 addresses the above points, but, I suggest that section 4.3 to be
restricted to ' link-layer OAM'

-- Section 6.4.1 --
"TTL field in NSH header to 63", not familiar with NSH, but, if there is a TTL
field in NSH, then it could be useful to point to the RFC & section describing
it. Esp in a section whose title is "ICMP" (referring obviously to the IP
header).

-- Section 8 --
In this security section, I wonder whether the trace tool deserves a paragraph
or two as if trusted while being forgeable/spoofed, then operators could trust
a SFC which is "owned" and not reliable (i.e., with a bypass of some security
SF). Trusting the security AD to raise a DISCUSS if they think it is a DISCUSS.

== NITS ==

-- section 6.3 --
Is it really required to re-specify the use of bit O in NSH ?

-- Section 6.4.1 --
Sigh... using the IPv4 terminology of TTL...

---

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

Hi Eric,

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

On 5/6/20, 8:24 AM, "Éric Vyncke via Datatracker" <[email-masked]> wrote:

    

<Nagendra> As you might have noticed, this document does not attempt to list a set of requirements. Instead, it proposes a structured layer and positions different SFC OAM components and explain the OAM  functionalities of such components and thereby making it easier for the solution documents to address the same. Accordingly, we believe this fit as a framework document (.

<Nagendra> Section 6 is about the candidate SFC OAM tools. But the other sections are equally important to better understand the overall context, different components followed by the toolset availability and the gaps. The Introduction section explains this for ease of reading. 

<Nagendra> Thank you for forwarding the comments from Carlos. We addressed the same and included the modification in the document.

    
    Regards,
    
    -éric
    
    == COMMENTS ==

<Nagendra> We got similar comments from other reviewers as well. We removed this section and updated by avoiding the use of normative statements.

<Nagendra> We briefly explained the applicability of In-Situ OAM in section 6.4.3. The overlay header (such as NSH) can carry iOAM data fields. The solution documents can detail the specifics of what data to collect or how to use it.

    -- Section 1 --
    
<Nagendra> Good point. I think we can modify the same as below:

OLD:
applied to packets and/or frames selected as a result

NEW:
applied to any traffic selected as a result..

    -- Section 2 --
    
<Nagendra> I think it is very much possible. Does the below text looks better?

OLD:
o  The link layer, which is tightly coupled with the physical
      technology used.  Ethernet is a popular choice for this layer, but
      other alternatives are deployed (e.g.  POS, DWDM).  The same or
      distinct link layer technologies may be used in each leg shown in
      Figure 1.

NEW:
o  The link layer, which is tightly coupled with the physical layer
      technology used.  Ethernet is a popular choice for this layer, but
      other alternatives are deployed (e.g.  POS, DWDM).  In a virtual environment, 
      virtualized I/O technologies such as SR-IOV or similar are applicable for this layer.
      The same or distinct link layer technologies may be used in each leg shown in
      Figure 1.

<Nagendra> We changed virtual machines as virtual entities so that it is not limited to VMs. Below is the modified text:

OLD:
In Figure 1, the service layer element such as classifier and SF are
   depicted as virtual machines that are interconnected using an overlay
   network.  The underlay network may comprise of multiple intermediate
   nodes but not shown in the figure that provides underlay connectivity
   between the service layer elements.

   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.

NEW:

In Figure 1, the service layer element such as classifier and SF are
   depicted as virtual entities that are interconnected using an overlay
   network.  The underlay network may comprise of multiple intermediate
   nodes but not shown in the figure that provides underlay connectivity
   between the service layer elements.

   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 entities, or any combination
   thereof.

    -- Section 3 --

<Nagendra> SFC being unidirectional, one-way delay measurement and packet loss was emphasized in section 4.4. We added the pointer as below:

OLD:
The second SFC OAM requirement for the SF component is to allow an
   SFC-aware network device to check the performance metrics such as
   loss and delay induced by a specific SF for processing legitimate
   traffic.  The performance can be a passive measurement by using live
   traffic or can be active measurement by using synthetic probe
   packets.

NEW:
The second SFC OAM requirement for the SF component is to allow an
   SFC-aware network device to check the performance metrics such as
   loss and delay induced by a specific SF for processing legitimate
   traffic.  The performance can be a passive measurement by using live
   traffic or can be active measurement by using synthetic probe
   packets. More details about this OAM function is explained 
in Section 4.4.
    
    -- Section 4.3 --

<Nagendra> Path MTU discovery is one of the connectivity functions and the above-mentioned scenario appears to be one possible case. Accordingly, I think this should be addressed in the respective solution document. 

<Nagendra> Not necessarily. The TTL handling mentioned in this document is about the TTL in the NSH/Overlay header. The traffic encapsulated by the overlay header can be L2 or L3.

<Nagendra> The NSH TTL field can be controlled to terminate the probe on any service layer element. So I think it is not limited to link-layer. 

    -- Section 6.4.1 --
    
<Nagendra> Make sense. Please see below for the modified text:

OLD:
can set the TTL field in NSH header to 63...
NEW:
can set the TTL field in NSH header [RFC8300] to 63...

    -- Section 8 --
    
<Nagendra> The section in ver-13 was updated based on the comments from SecDir review. Please feel free to share any text suggestions if you think the can be improved further.

    == NITS ==
    
    -- section 6.3 --
    
<Nagendra> I think we can leave it as it doesn’t appear to vitiate the meaning of the sentence (.

    -- Section 6.4.1 --

<Nagendra> The TTL discussed in this section is the field in the NSH header. 

Once again, thanks a lot for the great comments.

Thanks,
Nagendra