Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Jun 2020 09:42:14 -0400

The chairs are starting the WG last call for 
draft-ietf-sfc-proof-of-transit.  Please reply explicitly whether you 
think this is ready to go to the IETF for publication as a Experimental RFC.
As noted below, the call runs through June 30.

Note that silence does not imply consent, so please speak up.

Yours,
Joel (& Jim)

On 6/16/2020 9:32 AM, IETF Secretariat wrote:
> 
> The IETF WG state of draft-ietf-sfc-proof-of-transit has been changed to "In
> WG Last Call" from "WG Document" by Joel Halpern:
> 
> https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/
> 
> Comment:
> This starts WG last call for this document, ending June 30.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 19 Jun 2020 02:58:56 +0000

I believe this document is ready to progress towards publication as an Experimental RFC.

THanks,

Carlos.

> 2020/06/16 午前9:42、Joel M. Halpern <[email-masked]>のメール:
> 
> The chairs are starting the WG last call for draft-ietf-sfc-proof-of-transit.  Please reply explicitly whether you think this is ready to go to the IETF for publication as a Experimental RFC.
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Fri, 19 Jun 2020 06:35:32 +0000

Hi Franck, all, 

I know that you are working on this since a while. Please find below some comments on the YANG part to hopefully save you some cycles during upcoming reviews:

(1) Remove "?" from the explanation text in Section 5.2.1

(2) 

OLD: 
The meaning of the symbols in these diagrams is
   as follows:

   o  Brackets "[" and "]" enclose list keys.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write), and "ro" means state data (read-only).

   o  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes a list and leaf-list.

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

NEW:
  The meaning of the symbols in YANG tree diagrams is defined in [RFC8340].

(3) Remove <CODE BEGINS> and <CODE ENDS> from the tree diagram

(4) Instead of:

           +--rw active-profile-index?   profile-index-range 

You can define a status leaf under pot-profile-list to indicate the activation status.

(5) Any reason why are you using version 1? If not, please update to "1.1"

(6) As your groupings are called only once, and unless you want to define them as reusable by other modules, you may just define those as part of the main container.    

(7) IANA Section should be updated as follows: 

OLD:
   This document does not require any actions from IANA.

NEW:

   IANA is requested to register the following URI in the "ns" subregistry within
   the "IETF XML Registry" [RFC3688]:

      URI:  urn:ietf:params:xml:ns:yang:ietf-pot-profile
      Registrant Contact:  The IESG.
      XML:  N/A; the requested URI is an XML namespace.

   IANA is requested to register the following YANG module in the "YANG Module
   Names" subregistry [RFC7950] within the "YANG Parameters" registry.

      Name:  ietf-pot-profile
      Maintained by IANA:  N
      Namespace:  urn:ietf:params:xml:ns:yang:ietf-pot-profile
      Prefix:  ietf-pot-profile
      Reference:  RFC XXXX

(7) You should update the Security Section as per https://trac.ietf.org/trac/ops/wiki/yang-security-guideline. 

And a more general note: 

==
   Several deployments use Traffic Engineering, policy routing, Segment
   Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer
   packets through a specific set of nodes.  In certain cases,
   regulatory obligations or a compliance policy require operators to
   ^^^^^^^^^^^^^^^^^^^^^^
   prove that all packets that are supposed to follow a specific path
   are indeed being forwarded across and exact set of pre-determined
   nodes.
==

Do you have pointers to such regulatory obligations? It would be good to add a pointer if you are aware of any. Thanks. 

Hope this helps.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
> Envoyé : mardi 16 juin 2020 15:42
> À : [email-masked]
> Objet : Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 24 Jun 2020 16:11:34 +0000

Hi Med,

Thanks a lot for your comments. Please see inline (...FB)

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Freitag, 19. Juni 2020 08:36
> To: [email-masked]
> Cc: Joel M. Halpern <[email-masked]>; [email-masked]
> Subject: RE: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
> 
> Hi Franck, all,
> 
> I know that you are working on this since a while. Please find below some
> comments on the YANG part to hopefully save you some cycles during upcoming
> reviews:
> 

...FB: Will do.
>   The meaning of the symbols in YANG tree diagrams is defined in [RFC8340].

...FB: Good point. We can indeed get rid of the legacy text and refer to RFC8340.
> (3) Remove <CODE BEGINS> and <CODE ENDS> from the tree diagram

...FB: Will do.
> You can define a status leaf under pot-profile-list to indicate the activation

...FB: Very doable - especially since the open source implementation in VPP also only uses and active and a standby profile.
> (5) Any reason why are you using version 1? If not, please update to "1.1"

...FB: Nothing specific. The model got defined (and implemented as part of OpenDaylight) back in 2016.

> 
> (6) As your groupings are called only once, and unless you want to define them
> as reusable by other modules, you may just define those as part of the main
> container.

...FB: We could consider doing so. The reason why we kept the model fairly stable so far was that there is an existing implementation in open source (Opendaylight), hence the preference to not change things unless there is a real need. Would you be ok to stay with the current structure?

> (7) You should update the Security Section as per
> https://trac.ietf.org/trac/ops/wiki/yang-security-guideline.

...FB: ACK on both points above.
>    regulatory obligations or a compliance policy require operators to

...FB: One of the co-authors and initiators of POT, Stephen, might have more specific references available. 
>From what I know, there are company policies that require path verification. In case we don't find a formal reference, we'll change the statement in the next revision and avoid mentioning "regulatory obligations".

> Hope this helps.

Very helpful indeed. Thanks again.

Cheers, Frank
> > Envoyé : mardi 16 juin 2020 15:42 À : [email-masked] Objet : Re: [sfc]
> > IETF WG state changed for draft-ietf-sfc-proof-of-transit
> >
> > > The IETF WG state of draft-ietf-sfc-proof-of-transit has been
> > > changed to
> > "In
> _________________________________________________________________
> ________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.

---

From: <[email-masked]>
Date: Wed, 24 Jun 2020 16:18:53 +0000

Hi Franck, 

Thanks for the follow-up.

Please see inline. 

Cheers,
Med

> De : Frank Brockners (fbrockne) [mailto:[email-masked]]
> Envoyé : mercredi 24 juin 2020 18:12
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Cc : Joel M. Halpern; [email-masked]; Srihari Raghavan (srihari);
> [email-masked]
> Objet : RE: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit
> 
> Hi Med,
> 
> > You can define a status leaf under pot-profile-list to indicate the
> activation
> > status.
> 
> ...FB: Very doable - especially since the open source implementation in VPP
> also only uses and active and a standby profile.

[Med] Great. Thanks.

> OpenDaylight) back in 2016.

[Med] Then, please update the module to use 1.1.

> ...FB: We could consider doing so. The reason why we kept the model fairly
> stable so far was that there is an existing implementation in open source
> (Opendaylight), hence the preference to not change things unless there is a
> real need. Would you be ok to stay with the current structure?
> 

[Med] Fair enough. 

> > Do you have pointers to such regulatory obligations? It would be good to
> add a
> > pointer if you are aware of any. Thanks.
> 
> From what I know, there are company policies that require path
> verification. In case we don't find a formal reference, we'll change the
> statement in the next revision and avoid mentioning "regulatory
> obligations".
> 

[Med] Looks like a good plan.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Jun 2020 12:12:49 -0700

Dear Authors, Chairs, et al.,
I've read and reviewed the latest version of the draft. The document is
well-written and addresses the essential problem in a very elegant manner.
I have several questions on the applicability of the proposed solution to
SFC NSH:

   - several technologies listed in the Introduction

   Several deployments use Traffic Engineering, policy routing, Segment
   Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer
   packets through a specific set of nodes.

I think that adding more references to IETF documents that defined the
technology, e.g. RFC 8402, RFC 8595, would benefit the text.

   -  as noted above, the document mentions a number of techniques to steer
   a flow over the particular path, including SFC NSH. That does make lots of
   sense for the Introduction but, since this is SFC WG document, one can
   expect more information on how POT can be used in SFC NSH environment. It
   would certainly be beneficial to provide as an example of carrying POT data
   using some of these methods? I think that for the SFC WG SFC NSH is the
   most desirable example.  Currently, some pieces of information can be found
   in draft-ietf-ippm-ioam-data and some in draft-ietf-sfc-ioam-nsh. I've
   tried to put them all together for SFC NSH but I don't think that I've got
   the puzzle together. I appreciate it if you can help me understand (likely
   I've missed it in one of the drafts) which elements of an SFC, i.e. SFF,
   SF/SF Proxy, Classifier, are POT-acting nodes? Also, are there requirements
   for SFC elements specific to POT?
   - looking at section 4.5 draft-ietf-ippm-ioam-data
   <https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09#section-4.5> I
   think that it limits the number of POT profiles that are used to calculate
   the Cumulative on a node to two. profile-index-range is defined as 0,1 but
   without the reference, it is not easy to understand the reason for the
   limitation. This is probably just one example where the additional
   reference in YANG data model will be helpful (I've noticed only one and it
   is empty).
   - continuing on pot-profile-index, how it is used in the SFC
   environment? And what ensures that all POT nodes along the SFP have a
   consistent view of POT profiles.

Regards,
Greg

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 25 Jun 2020 08:01:23 +0000

Hi Greg,

Thanks a lot for your review and comments. Please find some notes/replies/thoughts inline (“..FB”)

From: sfc <[email-masked]> On Behalf Of Greg Mirsky
Sent: Mittwoch, 24. Juni 2020 21:13
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit

Dear Authors, Chairs, et al.,
I've read and reviewed the latest version of the draft. The document is well-written and addresses the essential problem in a very elegant manner.
I have several questions on the applicability of the proposed solution to SFC NSH:

  *   several technologies listed in the Introduction
   Several deployments use Traffic Engineering, policy routing, Segment
   Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer
   packets through a specific set of nodes.
I think that adding more references to IETF documents that defined the technology, e.g. RFC 8402, RFC 8595, would benefit the text.

…FB: Good catch. We’ll add references for the technologies mentioned.
·   as noted above, the document mentions a number of techniques to steer a flow over the particular path, including SFC NSH. That does make lots of sense for the Introduction but, since this is SFC WG document, one can expect more information on how POT can be used in SFC NSH environment. It would certainly be beneficial to provide as an example of carrying POT data using some of these methods? I think that for the SFC WG SFC NSH is the most desirable example.  Currently, some pieces of information can be found in draft-ietf-ippm-ioam-data and some in draft-ietf-sfc-ioam-nsh. I've tried to put them all together for SFC NSH but I don't think that I've got the puzzle together. I appreciate it if you can help me understand (likely I've missed it in one of the drafts) which elements of an SFC, i.e. SFF, SF/SF Proxy, Classifier, are POT-acting nodes? Also, are there requirements for SFC elements specific to POT?
…FB: An implementor of POT for SFC with NSH would indeed need to rely on several documents:
    - draft-ietf-sfc-proof-of-transit: for the POT concept and mechanism
    - draft-ietf-ippm-ioam-data: for the definition of POT related data fields in IOAM
    - draft-ietf-sfc-ioam-nsh: for the definition of the encapsulation of POT related data fields in IOAM into NSH
    What you seem to be missing is an architecture-level discussion of how the mix of POT+IOAM+NSH apply to the SFC architecture.
    IMHO this would best be addressed by an architecture-level document, because all of the above mentioned documents are focused on a specific subject and neither of the documents would be a good fit for an architecture level definition. IMHO the best place for that would be a “RFC 7665bis” document – i.e. we’d extend the SFC architecture with a discussion how POT applies.
On your specific question: Personally, I could see POT apply to SFF, SF/SF-Proxy, as well as Classifiers. It would depend on what the verification objective is, i.e. whether one would want to check whether a packet traversed a specific set of forwarder hops – or whether one would want to check whether a specific set of service functions (or proxies) have been visited, etc. But that is clearly an architecture level discussion.

  *   looking at section 4.5 draft-ietf-ippm-ioam-data<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09#section-4.5> I think that it limits the number of POT profiles that are used to calculate the Cumulative on a node to two. profile-index-range is defined as 0,1 but without the reference, it is not easy to understand the reason for the limitation. This is probably just one example where the additional reference in YANG data model will be helpful (I've noticed only one and it is empty).
  *   continuing on pot-profile-index, how it is used in the SFC environment? And what ensures that all POT nodes along the SFP have a consistent view of POT profiles.
… FB: We’ll add some additional explanation that 0,1 refer to non-active/active POT profiles, which are communicated to the nodes from a controlling entity (this is what in the open source implementation is done by OpenDaylight – and which is why we have the definition of the POT YANG model in the first place) and that one switches between the two.
Thanks again, Frank

Regards,
Greg

On Tue, Jun 16, 2020 at 6:42 AM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
The chairs are starting the WG last call for
draft-ietf-sfc-proof-of-transit.  Please reply explicitly whether you
think this is ready to go to the IETF for publication as a Experimental RFC..
As noted below, the call runs through June 30.

Yours,
Joel (& Jim)

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 25 Jun 2020 16:33:38 +0000

Hi,

I support the publication of this draft as Experimental RFC.

Thanks,
Nagendra

On 6/16/20, 9:42 AM, "sfc on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    Yours,
    Joel (& Jim)

---

From: <[email-masked]>
Date: Thu, 25 Jun 2020 19:38:00 +0000

Hi Steve,

Thank you for sharing this pointer. Much appreciated.

I'm sure I'm missing something, but I don't quite see how this is related to proof of transit.

Can you please clarify? Thank you.

Cheers,
Med

De : Youell, Stephen [mailto:[email-masked]]
Envoyé : jeudi 25 juin 2020 15:30
À : BOUCADAIR Mohamed TGI/OLN; 'Frank Brockners (fbrockne)'; [email-masked]'
Cc : 'Joel M. Halpern'; [email-masked]'; 'Srihari Raghavan (srihari)'
Objet : RE: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit

Hi Med,
Responding on the reference question you had for "regulatory requirements" I would suggest:

[PCI-DSS] "Payment Card Industry (PCI) Data Security Standard",
          <https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf>

More specifically it is requirement 1 which I have taken the pertinent text from below:

Page 20: Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 1.1.1: A formal process for approving and testing all network connections and changes to the firewall and router configurations
Testing procedure:

-          Examine documented procedures to verify there is a formal process for testing and approval of all: * Network connections and * Changes to firewall and router configurations

-          For a sample of network connections, interview responsible personnel and examine records to verify that network connections were approved and tested.
Guidance: A documented and implemented process for approving and testing all connections and changes to the firewalls and routers will help prevent security problems caused by misconfiguration of the network, router, or firewall. Without formal approval and testing of changes, records of the changes might not be updated, which could lead to inconsistencies between network documentation and the actual configuration.

Regards,
Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, June 24, 2020 5:19 PM
To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Srihari Raghavan (srihari) <[email-masked]<mailto:[email-masked]>>; Youell, Stephen <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit

Hi Franck,

Please see inline.

Cheers,
Med

> De : Frank Brockners (fbrockne) [mailto:[email-masked]<mailto:[email-masked]>]
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]<mailto:[email-masked]>
> Cc : Joel M. Halpern; [email-masked]<mailto:[email-masked]>; Srihari Raghavan (srihari);
> [email-masked]<mailto:[email-masked]>
> > From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

[Med] Great. Thanks.

[Med] Fair enough.

> > > De : sfc [mailto:[email-masked]<mailto:[email-masked]>] De la part de Joel M. Halpern
> > > Envoyé : mardi 16 juin 2020 15:42 À : [email-masked]<mailto:[email-masked]> Objet : Re: [sfc]

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 29 Jun 2020 23:22:01 +0530

Hi,

The document is in a good shape for publication as an Experimental
RFC. Just a few comments that can handled along the way -

- Abstract,  Add a sentence about the presence of a Yang model in this I-D
- Section 1, Add a reference when the Shamir's Secret Sharing on first use
Also you have it as a normative reference to a wiki page -

[SSS]      "Shamir's Secret Sharing",
              <https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>.

Isn't there a better reference for this which is archival in nature
and cant be modified easily?

- Section 2, Use the updated boilerplate for capitalized keywords -

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

- Section 5, You include -

   This document does not
   define a specific protocol to be used between Controller and nodes.
   It only defines the procedures and the associated YANG data model.

That is true for all documents with yang models, any reason to be
explicit about it?

- Section 5.2.2, You should include this -

   A simplified graphical representation of the data model is used in
   this document.  The meaning of the symbols in these diagrams is
   defined in [RFC8340].

instead of repeating the tree notations.

- Section 5.2.3,
    o  Update the dates in the Yang model as well the year in the copyright
    o  Query: Should nacm be used in the Yang model for the secret leaves?

- Section 6
   o  Don't we need to update the IANA consideration for the Yang model?

- Section 7.8
   o  Needs to be enhancecd to also include yang related security as
per https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Thanks!
Dhruv