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

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

Hi Eric,

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

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

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

    The core of the document appears to be section 6: this should probably be
    reflected in the abstract and introduction
    
<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. 

    Please address the comments raised in the Internet directorate review by Carlos
    Bernardos:
    https://mailarchive.ietf.org/arch/msg/int-dir/TgQulH7hytGPNxdAPWcSgkTx1IM
  
<Nagendra> Thank you for forwarding the comments from Carlos. We addressed the same and included the modification in the document.

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

    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...)?.
   
<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 --
    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 ?
    
<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 --
    Is there a reason why all 'virtual links' are not mentioned in this section?
    I.e., SR-IOv network, tun/tap, ...
    
<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.

    Similar question about why limiting the example of VM and not including
    containers ?
    
<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 --
    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.

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

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

    Section 5.2 addresses the above points, but, I suggest that section 4.3 to be
    restricted to ' link-layer OAM'
    
<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 --
    "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).
    
<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 --
    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.
    
<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 --
    Is it really required to re-specify the use of bit O in NSH ?
    
<Nagendra> I think we can leave it as it doesn’t appear to vitiate the meaning of the sentence (.

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

<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