Subject: [sfc] Intdir telechat review of draft-ietf-sfc-oam-framework-13

From: Carlos Bernardos via Datatracker <[email-masked]>
Date: Mon, 04 May 2020 05:30:23 -0700

Reviewer: Carlos Bernardos
Review result: Ready with Nits

Thanks a lot for this document. I liked reading it.

I have a first generic comment, minor but that I still wanted to make. Section
2 is about SFC Layering Model, which to me seems like an introduction, but not
really specifically related to the core topic of the draft. Do we need that
section in this draft? Maybe it can be condensed and included as a first part
of section 3.

The document has a big component of requirements and gap analysis, which brings
one question: should the document use normative RFC 2199 language when
expressing the requirements? In Section 3.2.1 t is used, for example, but not
in other parts. I think some work is needed to make this consistent.

I think that the following sentence needs to be reworded: "In order to apply
such OAM functions at the service layer, they need to be enhanced to operate a
single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs."

I think the behaviour of SFC-aware nodes that do not support a given OAM
operation should be better explained. For example, the sentence "When an SF
supports OAM functionality, it is desirable to process the packet and provide
an appropriate response to allow end-to-end verification." might be to vague.

Table 4 has a small formatting issue in the Classifier row.

I think some in-band vs out-band OAM discussion would be interesting to add to
the document.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 6 May 2020 12:35:47 +0000

Thank you Carlos for your review.

I used your review to ballot on the document for the 7th of May IESG telechat except for the reference to BCP 14 in an informational document (and usually architecture documents are indeed informational).

Best regards

-éric

-----Original Message-----
From: Int-dir <[email-masked]> on behalf of Carlos Bernardos via Datatracker <[email-masked]>
Reply-To: Carlos Bernardos <[email-masked]>
Date: Monday, 4 May 2020 at 14:30
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Int-dir] Intdir telechat review of draft-ietf-sfc-oam-framework-13

    _______________________________________________
    Int-dir mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/int-dir

---

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

Hi Carlos,

Thank you for the review and sharing the comments. Please see inline for the responses:

On 5/4/20, 8:30 AM, "Carlos Bernardos via Datatracker" <[email-masked]> wrote:

    
    
<Nagendra> Section 2 splits the SFC into layers that helps associate different SFC OAM components and its dependency on different layers. For ease of reading, I think we will leave it in this section.

<Nagendra> I hope you are referring to RFC2119 (BCP 14). We got similar comments from other reviewers and agreed to remove the section and avoid using any normative statements.

<Nagendra>Ok. We modified it as below. Hope that clarifies:

OLD:
 
In order to apply
   such OAM functions at the service layer, they need to be enhanced to
   operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in
   multiple SFCs.
   
NEW:
In order to apply
   such OAM functions at the service layer, they need to be enhanced to
   apply the OAM function on a single SF/SFF or multiple SFs/SFFs 
   spanning across one or more SFCs.

<Nagendra> This is explained in the previous sentence as below:

" Upon receiving an OAM packet, SFC-aware SFs may choose to discard the
   packet if it does not support OAM functionality or if the local
   policy prevents them from processing the OAM packet."

<Nagendra> Thank you. Fixed it and will be reflected in the new revision. 

   <Nagendra> While the whole document primarily focused on out-band, section 6.4 already talks about the applicability of In-band OAM tool to perform the OAM functions.
    
Once again, thanks a lot for the great comments.

Thanks,
Nagendra