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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Alissa,

Following up on your DISCUSS — could you please check if the clarification below plus the changes -13 -> -15 address your concern, or if there’s more you’d like to DISCUSS?

https://www.ietf.org/rfcdiff?url1=draft-ietf-sfc-oam-framework-13&url2=draft-ietf-sfc-oam-framework-15 <https://www.ietf.org/rfcdiff?url1=draft-ietf-sfc-oam-framework-13&url2=draft-ietf-sfc-oam-framework-15>

Many thanks,

C.

> 2020/05/18 午前5:40、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
> 
> 
> 
> 
>