I have a fly-by response to this which is to say that "service degraded" is not the same as "service down".
Consider a p2mp service where one leaf is suddenly not reachable. You might say that the contracted service is not being delivered, but it will often be "almost completely" being delivered. It is degraded but failed.
Similarly, an L3VPN service where a site becomes unreachable.
Thus SAP failure does not always imply service failure.
Adrian
On 06/11/2022 16:50 Rob Wilton (rwilton) <rwil...@cisco.com> wrote:
Hi Med,
Apologies for the delay. The behaviour is still not entirely clear to me. Please see inline ...
-----Original Message-----Sent: 29 September 2022 15:18To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg-Subject: RE: AD review of draft-ietf-opsawg-sap-09
Hi Rob,
Thanks for the follow-up.
Please see inline.
Cheers,Med
-----Message d'origine-----De : Rob Wilton (rwilton) <rwil...@cisco.com>Envoyé : jeudi 29 septembre 2022 15:24À : BOUCADAIR Mohamed INNOV/NETObjet : RE: AD review of draft-ietf-opsawg-sap-09Hi Med,Comments inline below ...I've snipped out anything that we have already reached agreementon.>-----Original Message-----Sent: 23 September 2022 14:04To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg-Subject: RE: AD review of draft-ietf-opsawg-sap-09Hi Rob,Thank you for the review. The changes can be tracked at:Please note that I made a change to better allow for reuse ofthe SAPinformation in other modules (this can be tracked here:WG/lxnm/commit/e8b406d7fad5225dd84ad7ff03f6da446eae6736).Okay.>Please see inline for more context.Cheers,Med-----Message d'origine-----De : Rob Wilton (rwilton) <rwil...@cisco.com> Envoyé :vendredi 23septembre 2022 14:01 À : draft-ietf-opsawg-sap....@ietf.org;opsawg@ietf.org Objet : AD review of draft-ietf-opsawg-sap-09Hi authors, WG,Thank you for this document. I also think that this documentiswell written and in good shape, and I mostly found theexplanationsand examples clear. There were two specific points that Ifoundslightly confusing related to differentiating between SAPs inuse,and those that are not, and also parent interfaces also belisted asSAPs, details below.[Med] ThanksModerate level comments:(1) p 10, sec 5. SAP Module Tree StructureSAPs that are associated with the interfaces that aredirectlyhosting services, interfaces that are ready to host per-servicesub-interfaces (but not yet activated), or service thatarealready instantiated on sub-interfaces are listed asSAPs.From the model, is isn't clear to me how differentdifferentiatesbetween a SAP that has been pre-provisioned to potentially beusedfor a service in future, v.s., one is that is activelyprovisioned.>[Med] This is inferred from the service-status=down for theseSAPs.So, thinking of this at device level configuration there iseffectively 3 levels of configuration/activation (at least forL2VPNs):(1) A sub-interface is configured, but without any IP address orVRF (for L3VPN), or without being attached to an L2VPN or BridgeDomain (for L2VPNs). I.e., the sub-interface isn't connectedanyway.(2) The sub-interface is configured and connected into a bridgedomain or P2P L2VPN but that service is down (e.g., perhapsbecause the AC at the remote end of the L2VPN is physically down).(3) The sub-interface is configured and connected into a bridgedomain or P2P L2VPN and that service is up.I think that you are saying that you regard that both (1) and (2)would be indicated by service-status=down? Would it be worthexpanding the description at all to make this more explicit?[Med] The implicit model has some limitations, indeed. Glad to see that wereached the same conclusion. Please see this note I sent early this week:kj4/
ButI'm still not convinced this will be sufficient (e.g., see myfollowing response below related to the example for selecting aservice).>I think that it would be helpful if these two casescan be clearly distinguished. Note, I have made a similarcommentrelated to appendix D about identifying a "free" SAP.[Med] Added this NEW to the appendix:"SAPs that are ready to host per-service (but not yet activated)areidentified by the "service-status" set to "ietf-vpn-common:op-down"."But how do you distinguish between a SAP that hasn't beenprovisioned yet to a service vs a SAP that has been provisionedbut the service is down? E.g., trying to find a free SAP just bylooking for a SAP with a service-status of op-down doesn't appearto be sufficient on its own.[Med] A SAP that is not provisioned yet will have a sap-status=down, whilethe one that is provision but the service is not activated will have sap-status=up and service-status=down. Isn't that sufficient?I would have assumed:- If sap-status is down then the service-status must also be down, right?- if the sap is a sub-interface and the parent be down? Hence, interface is down, then the sap-status would also I would have thought that you cannot distinguish between it not being provisioned and it is provisioned but the SAP is down either due to the parent, or perhaps the sub-interface has explicitly been forced down for some reason (perhaps due to config, or other reasons).
Perhaps you are saying that this isn't a problem in practice?
>>>>(2) p 28, sec Appendix B. A Simple Example of SAP NetworkModel:Node Filter[Med] Please note "Simple" in the title :-)OK, noted. ;-)>A service orchestrator can query what services are providedonwhichSAPs of PE1 from the network controller by sending, e.g., aGETRESTCONF request. Figure 9 shows the body of the RESTCONFresponsethat is received from the network controller.In this example, you have GE0/6/4 as being ready to host SAPs,but Icould equally imagine that given GE0/6/4 is just a UNI, thenyou maynot want the parent interface to be available to host SAPsdirectlyat all. I.e., it may always the case that sub-interfaces areusedas SAPs. Hence, did you consider whether it makes sense forthereto be a different category of SAP service-types for UNI's andNNI'sthat don't host services directly on the interface, but alwaysonsub-interfaces?[Med] Yes, we do need this for the LxVPN case.It's still not clear to me. E.g., in the example, GE0/6/4 islisted as an VPLS SAP and as an L3VPN SAP,[Med] I see. That SAP is a special one as it tags an interface that is ready tohost per-service sub-interfaces. This is now clearly indicated by the new leaf"ready-child-sap". This is some kind of root or parent SAP.Okay.
So, does "ready-child-sap" mean that the interface itself cannot be directly bound to a service, and only the child SAPs can be? Or does it mean that a service could be bound both to the sap itself, and also as child SAPs? Either way, I think that it would be helpful for that to be documented/clarified.
I still not a big fan of the name "ready-child-sap", because it seems to describe a point of time rather that what it is. Would something like "allows-child-saps" or "child-sap-capable" be clearer?
and it isn't obviousthat it is actually either of those. I.e., really it is just aparent to sub-interfaces that represent the VPLS and L3VPN SAPs.[Med] These SAPs fall under:
SAPs that are associated with the interfaces that are directlyhosting 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.
>Hence, I was asking whether you considered putting GE0/6/1 into adifferent service/sap list (e.g., of service-type "sap-parent"),or similar. This would mean that the interface would be listedonly once rather than under both VPLS and L3VPN.[Med] We are listing them per service because some interfaces may berestricted to specific services. In the example, it happen that this interface isready to hots both VPLS/L3VPN, but there might be cases where a "parent"SAP will listed only for a single service.Okay.
>>Related to this, itfeels slightly strange to me to have GE0/6/4 listed under bothl3vpnand vpls SAP lists.[Med] Actually there are attached to distinct sub-interfaces:So, my question is really whether, in this case, GE0/6/4 isactually a SAP at all, or whether really it is only the child sub-interfaces of GE0/6/4 that are actually SAPs?[Med] It is a special SAP. We need to have it listed as such because otherwisewe can't display where a service can be delivered unless a child SAP isexplicitly instantiated.
>Possibly adding the "ready-child-sap" resolves this ambiguity.[Med] Agree.
Possibly, I would have a chosen a different name and descriptionfor this leaf (e.g., "sap-parent") that indicates that this nodecan act as a parent to other SAPs.>Also, let us assume that, forthe SAPs that are associated with the physical interface"GE0/6/4",VPLS and L3VPN services are activated on the two sub-interfaces"GE0/6/4.1" and "GE0/6/4.2", respectively.Updated the example to align with this text.Having the same information twice inthe data model introduces the risk that a device could exportinconsistent information and hence it hard for the customer toknowwhich data is accurate. I can understand why having it twicemightbe convenient, but having an indication that it is actuallyjust acontainer node for SAPs rather than a SAP itself might bebetter.>>Minor level comments:(5) p 10, sec 5. SAP Module Tree StructureThese service types build on the types that are alreadydefinedin[RFC9181] and additional types that are defined in thisdocument.Other service types can be defined in future YANG modules,ifneeded.In future YANG modules, or perhaps also future versions of theYANGmodel defined in this document?[Med] Changed to "future YANG modules (including futurerevisions ofthe YANG model defined in this document)"Okay.>>(9) p 17, sec 6. SAP YANG Moduleleaf peer-sap-id {type string;description"Indicates an identifier of the peer'sterminationidentifier (e.g., Customer Edge (CE)). Thisinformation can be used for correlationpurposes,such as identifying the SAP that is attached toan endpoint that is provided in a servicerequest.";}Would it be helpful to indicate that the "peer-sap-id" is notnecessarily the same as the peer's sap_id for that sameattachmentcircuit endpoint? E.g., it appears to differ in your exampleinAppendix C.[Med] Given that this is used for correlation purposes, thevalueenclosed in peer-sap-id is useful when it is known to the peer.Typically, that value will be indicated as the service deliverypoint. I tend to leave the description as it is.Okay, the reason that I queried this was that in your appendix C,you don't appear to follow this. E.g., the peer_sap_id for"sap#12" is given as "asbr-b1", but that is probably not what thepeer sap id would actually be (or otherwise all the "peer_sap_id"names would collide). Perhaps this example is an exception to therule, but then that would be worth highlighting in the text thatdescribes the example.>
[Med] Fair. I added the following:
" This identifier may or may not be the same as the SAP identifier used in thepeer's configuration. Note that the use of identical identifiers easescorrelation between a peer's service request with a local SAP. "Looks good. Thanks.
Regards,Rob
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg