Re: [sfc] Alissa Cooper's Discuss on draft-ietf-sfc-oam-framework-13: (with DISCUSS and COMMENT)

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

HI Alissa,

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

    Alissa Cooper has entered the following ballot position for
    draft-ietf-sfc-oam-framework-13: Discuss
    
    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/
    
    
    
    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------
    
    Table 3 has "None" in all the cells corresponding to SF and SFC OAM functions.
    But then Sections 6.4.1 through 6.4.4 discuss several tools that can be used to
    provide some of these functions. I understand that the text about the table
    says "Table 3 below is not exhaustive," but still it seems misleading to say
    "None" in the table when there are, in fact, tools available that are discussed
    just a few paragraphs later.
    
<Nagendra> Unlike the underlay/overlay networks where these tools work natively, the application of the existing OAM tools in SFC elements comes with some assumption that the SF is capable of differentiating the OAM packets using overlay header signaling or by other means and process/reply accordingly. Section 6.4.x explains how these can be applied for SFC OAM function but not how it works currently. Accordingly, we believe that this is still a gap and so prefer leaving it as "None". We can update the section to reflect that table is listing the tools that "natively" work.
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Section 4.1: "Verify the policy of an SFC or SF." --> This seems a little
    vague. What about the policy is meant to be verified?
    
<Nagendra> AFAIK, policy is an integral part of the SFC architecture allowing the operators to define the traffic classification rules, the set of SFs to be applied and the order in which the SFs should be applied etc. The above listed point appears to be straightforward. Please let us know your suggestion for text preference if there is any ambiguity.  

    Section 6: The title of this section threw me off. I would suggest putting
    Section 6.1, 6.2, and 6.3 into one section about "Operational Aspects of SFC
    OAM at the Service Layer" and then starting a new Section 7 about "Candidate
    SFC OAM Tools" that begins with the current Section 6.4 text.

<Nagendra>This can be done. We will move 6.1,6.2,6.3 to a separate section.
    
    Section 6.1: The normative language seems out of place here.

<Nagendra> Based on the comments from various reviewers, we removed the use of normative statement in this document.

Once again, thanks a lot for the great comments.

Regards,
Nagendra