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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
