[OPSAWG] AD review of draft-ietf-opsawg-sap-09

["Rob Wilton (rwilton)" <[e-mail]>]

Hi authors, WG,

Thank you for this document.  I also think that this document is well written and in good shape, and I mostly found the explanations and examples clear.  There were two specific points that I found slightly confusing related to differentiating between SAPs in use, and those that are not, and also parent interfaces also be listed as SAPs, details below.

Moderate level comments:

(1) p 10, sec 5.  SAP Module Tree Structure

      SAPs that are associated with the interfaces that are directly
      hosting services, interfaces that are ready to host per-service
      sub-interfaces (but not yet activated), or service that are
      already instantiated on sub-interfaces are listed as SAPs.

>From the model, is isn't clear to me how different differentiates between a SAP that has been pre-provisioned to potentially be used for a service in future, v.s., one is that is actively provisioned.  I think that it would be helpful if these two cases can be clearly distinguished.  Note, I have made a similar comment related to appendix D about identifying a "free" SAP.


(2) p 28, sec Appendix B.  A Simple Example of SAP Network Model: Node Filter

   A service orchestrator can query what services are provided on which
   SAPs of PE1 from the network controller by sending, e.g., a GET
   RESTCONF request.  Figure 9 shows the body of the RESTCONF response
   that is received from the network controller.

In this example, you have GE0/6/4 as being ready to host SAPs, but I could equally imagine that given GE0/6/4 is just a UNI, then you may not want the parent interface to be available to host SAPs directly at all.  I.e., it may always the case that sub-interfaces are used as SAPs.  Hence, did you consider whether it makes sense for there to be a different category of SAP service-types for UNI's and NNI's that don't host services directly on the interface, but always on sub-interfaces?  Related to this, it feels slightly strange to me to have GE0/6/4 listed under both l3vpn and vpls SAP lists.  Having the same information twice in the data model introduces the risk that a device could export inconsistent information and hence it hard for the customer to know which data is accurate.  I can understand why having it twice might be convenient, but having an indication that it is actually just a container node for SAPs rather than a SAP itself might be better.



Minor level comments:

(3) p 3, sec 3.  Sample SAP Network Model Usage

   Management operations of a service provider network can be automated
   using a variety of means such as interfaces based on YANG modules
   [RFC8969].

Would a reference to NETCONF and potentially RESTCONF be helpful here in addition to RFC8969?


(4) p 4, sec 3.  Sample SAP Network Model Usage

   The service orchestration layer does not need to know about the
   internals of the underlying network (e.g., P nodes).

Would "all the internals" be better than just "internals".  I.e., presumably the service orchestration layer probably does need to know about some of the internals of the underlying network.


(5) p 10, sec 5.  SAP Module Tree Structure

   These service types build on the types that are already defined in
   [RFC9181] and additional types that are defined in this document.
   Other service types can be defined in future YANG modules, if needed.

In future YANG modules, or perhaps also future versions of the YANG model defined in this document?


(6) p 11, sec 5.  SAP Module Tree Structure

      This data node can be used, for example, to decide whether an
      existing SAP can be (re)used to host a service or if a new sub-
      interface has to be instantiated.

So, is this field effectively also being used to determine if the SAP is in use?


(7) p 12, sec 5.  SAP Module Tree Structure

      When both a sub-interface and its parent interface are present,
      the status of the parent interface takes precedence over the
      status indicated for the sub-interface.

This seems strange to me.  E.g., if the parent-interface was up, but the sub-interface was administratively down then would you be expected to report the sap-status as up?  I would think that this should always be reporting the sub-interface state, but that the sub-interface state should inherit


(8) p 16, sec 6.  SAP YANG Module

     identity logical {
       base interface-type;
       description
         "Refers to a logical sub-interface that is typically
          used to bind a service. This type is used only
          if none of the other logical types can be used.";
     }

Perhaps clarify what you mean by "other logical types".  E.g., do you just mean loopback or irb, or does this include local-bridge as well?


(9) p 17, sec 6.  SAP YANG Module

         leaf peer-sap-id {
           type string;
           description
             "Indicates an identifier of the peer's termination
              identifier (e.g., Customer Edge (CE)). This
              information can be used for correlation purposes,
              such as identifying the SAP that is attached to
              an endpoint that is provided in a service request.";
         }

Would it be helpful to indicate that the "peer-sap-id" is not necessarily the same as the peer's sap_id for that same attachment circuit endpoint?  E.g., it appears to differ in your example in Appendix C.


(10) p 19, sec 8.  Security Considerations

   *  /nw:networks/nw:network/nw:node/sap:service-type/sap:sap

Should this be: /nw:networks/nw:network/nw:node/sap:service/sap:sap ?


(11) p 20, sec 8.  Security Considerations

   *  /nw:networks/nw:network/nw:node/sap:service-type/sap:sap

Should this be: /nw:networks/nw:network/nw:node/sap:service/sap:sap ?


(12) p 25, sec Appendix A.  A Simplified SAP Network Example

   An example of a SAP topology that is reported by a network controller
   is depicted in Figure 7.  This example echoes the topology shown in
   Figure 4.  Only a minimum set of information is provided for each
   SAP.

I'm surprised that service-status isn't reported for the saps that only have names.  Perhaps that information is elided to make the examples shorter, but it may be helpful to clarify that.  E.g., perhaps expand "Only a minimum set of information is provided for each
   SAP." to be explicit about SAP information that has been elided (e.g., attachment interface, interface type, role).  Or perhaps a bit more of an explanation about how different SAPS are being modelled here would be helpful.


(13) p 28, sec Appendix B.  A Simple Example of SAP Network Model: Node Filter

   A service orchestrator can query what services are provided on which
   SAPs of PE1 from the network controller by sending, e.g., a GET
   RESTCONF request.  Figure 9 shows the body of the RESTCONF response
   that is received from the network controller.

I think that it would be helpful to explicitly include the path of the request that is being made here to help provide the full context of the response.


(14) p 34, sec Appendix C.  An Example of NNI SAP: Inter-AS VPN Option A

                     {
                       "sap-id": "sap#13",
                       "description": "vpn1",
                       "role": "ietf-sap-ntw:nni",
                       "peer-sap-id": "asbr-b1",
                       "service-status": {
                         "status": "ietf-vpn-common:op-up"
                       }
                     },
                     {
                       "sap-id": "sap#14",
                       "description": "vpn2",
                       "role": "ietf-sap-ntw:nni",
                       "peer-sap-id": "asbr-b1",
                       "service-status": {
                         "status": "ietf-vpn-common:op-up"
                       }
                     }

Is it right for vpn1 and vpn2 to be listed as role nni?  I would think that only the underlying links as NNIs?
## Other than the description it isn't entirely obvious to me how the services are differentiated from the NNI interfaces.  E.g., similar to a previous comment, I think that it feels slightly strange to me that the parent NNI interfaces are also listed as part of the l3vpn service.
## Further, the description above states that each of the VPNs would be identified by a sub-interface, but that isn't obvious here (the attachment-interface and parent-termination-point are not included in any of the output.)


(15) p 35, sec Appendix D.  An Example of Using the SAP Network Model in Service
             Creation

   Let us assume that an operator wants to create an L3VPN service
   between two PEs (PE3 and PE4) that are servicing two CEs (CE6 and
   CE7).  To that aim, the operator would query the SAP topology and
   would obtain a response similar to what is depicted in Figure 7.
   That response indicates that the SAPs having "sap#31" and "sap#43" as
   attachment identifiers do not have any installed services.  Once the
   "free" SAPs are identified, the 'interface-type' and 'encapsulation-
   type' are checked to see if the requested L3VPN service is compatible
   with the SAP characteristics.  If they are compatible, as proposed in
   Section 5, the 'attachment-id' value can be used as the VPN network
   access identifier in an L3NM create query.

How does it identify a "free" SAP?  If it is the absence of other attributes, then how does it check that "interface-type" and "encapsulation-type"?


(16) p 35, sec Appendix D.  An Example of Using the SAP Network Model in Service
             Creation

   Let us now assume that, instead of the L3VPN service, the operator
   wants to set up an L2VPN service.  If the 'interface-type' is a
   physical port, a new logical SAP can be created using the SAP model
   to cope with the service needs (e.g., the 'encapsulation-type'
   attribute can be set to 'ietf-vpn-common:vlan-type').  Once the
   logical SAP is created, the 'attachment-id' of the new SAP is used to
   create an L2NM instance (Section 7.6 of [I-D.ietf-opsawg-l2nm]).

So, in your two examples, one of them is re-using predefined SAPs for L3VPN, and the other creating new ones for L2VPN.  Presumably you could also provision L3VPN services creating new SAPs and provision L2VPN services using existing by unused L2 SAPS?  Perhaps it would be helpful to expand on this a bit?



Nit level comments:

(17) p 3, sec 2.  Terminology

   Customer Edge (CE):  An equipment that is dedicated to a particular
      customer and is directly connected to one or more PEs via ACs.

An equipment that => "Equipment that is" or "Item of equipment that is".  The same comment applies to the PE definition below.


(18) p 3, sec 2.  Terminology

       A
      CE is usually located at the customer premises.  A CE may be
      dedicated to a single service (e.g., L3VPN), although it may
      support multiple VPNs if each one has separate attachment
      circuits.  A CE can be a router, a bridge, a switch, etc.

Suggest "or" rather than "although"


(19) p 4, sec 3.  Sample SAP Network Model Usage

     Figure 2 shows
   the abstract network view as seen by a service orchestrator.
   However, this view is not enough to provide to the service
   orchestration layer the information to create services in the
   network.  The service topology need is to be able to expose the set
   of nodes and the attachment points associated with the nodes from
   which network services can be grafted (delivered).

I suggest some minor rewording:

   However, this view is not enough to provide the service
   orchestration layer with the necessary information to create services in the
   network.  The service topology also needs to expose the set
   of nodes and the attachment points associated with the nodes from
   which network services can be grafted (delivered).


(20) p 5, sec 3.  Sample SAP Network Model Usage

   As shown in Figure 4, the service orchestration layer will have also
   access to a set of customer service model (e.g., the L3SM or the
   L2SM) in the customer-facing interface and a set of network models
   (e.g., the L3NM and network topology data models) in the resource-
   facing interface.  In this use case, it is assumed that the network
   controller is unaware of what happens beyond the PEs towards the CEs;
   it is only responsible for the management and control of the SAPs and
   the network between PEs.  In order to correlate between delivery
   points expressed in service requests and SAPs, the SAP model may
   include a peer customer point identifier.  That identifier can be a
   CE identifier, a site identifier, etc.

"set of customer srevice model" -> "set of customer service models"

And some automated, very minor grammar nits, that you may wish to check:

Grammar Warnings:
Section: 4, draft text:
In the context of Software-Defined Networking (SDN) [RFC7149][RFC7426], the SAP YANG data model can be used to exchange information between control elements, so as to support VPN service provision and resource management discussed in [RFC9182][I-D.ietf-opsawg-l2nm]. 
Warning:  'So as to' expresses purpose and is used in formal texts. Consider using to
Suggested change:  "to"

Section: 5, draft text:
Whether the attachment identifier echoes the content of the attachment interface is deployment specific. 
Warning:  "Whether" at the beginning of a sentence usually requires a 2nd clause. Maybe a comma, question or exclamation mark is missing, or the sentence is incomplete and should be joined with the following sentence.

Section: 8, draft text:
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. 
Warning:  If the text is a generality, 'of the' is not necessary.
Suggested change:  "Some"

Thanks,
Rob