Hi Med, Apologies for the delay. The behaviour is still not entirely clear to me. Please see inline ...
> -----Original Message----- > From: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > Sent: 29 September 2022 15:18 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg- > sap....@ietf.org; opsawg@ietf.org > 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/NET > <mohamed.boucad...@orange.com>; > > draft-ietf-opsawg-sap....@ietf.org; opsawg@ietf.org > > Objet : RE: AD review of draft-ietf-opsawg-sap-09 > > > > Hi Med, > > > > Comments inline below ... > > > > I've snipped out anything that we have already reached agreement > > on. > > > > > > > -----Original Message----- > > > From: mohamed.boucad...@orange.com > > > <mohamed.boucad...@orange.com> > > > Sent: 23 September 2022 14:04 > > > To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg- > > > sap....@ietf.org; opsawg@ietf.org > > > Subject: RE: AD review of draft-ietf-opsawg-sap-09 > > > > > > Hi Rob, > > > > > > Thank you for the review. The changes can be tracked at: > > > https://tinyurl.com/sap-latest > > > > > > Please note that I made a change to better allow for reuse of > > the SAP > > > information in other modules (this can be tracked here: > > > https://github.com/IETF-OPSAWG- > > > 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 23 > > > > septembre 2022 14:01 À : draft-ietf-opsawg-sap....@ietf.org; > > > > opsawg@ietf.org Objet : AD review of draft-ietf-opsawg-sap-09 > > > > > > > > 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. > > > > > > [Med] Thanks > > > > > > > > > > > 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. > > > > > > [Med] This is inferred from the service-status=down for these > > SAPs. > > > > So, thinking of this at device level configuration there is > > effectively 3 levels of configuration/activation (at least for > > L2VPNs): > > > > (1) A sub-interface is configured, but without any IP address or > > VRF (for L3VPN), or without being attached to an L2VPN or Bridge > > Domain (for L2VPNs). I.e., the sub-interface isn't connected > > anyway. > > (2) The sub-interface is configured and connected into a bridge > > domain or P2P L2VPN but that service is down (e.g., perhaps > > because the AC at the remote end of the L2VPN is physically down). > > (3) The sub-interface is configured and connected into a bridge > > domain 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 worth > > expanding the description at all to make this more explicit? > > [Med] The implicit model has some limitations, indeed. Glad to see that we > reached the same conclusion. Please see this note I sent early this week: > https://mailarchive.ietf.org/arch/msg/opsawg/C_aI8qsGbdUif9Ems8bN0s3E > kj4/ > > > But > > I'm still not convinced this will be sufficient (e.g., see my > > following response below related to the example for selecting a > > service). > > > > > > > > > > > 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. > > > > > > [Med] Added this NEW to the appendix: > > > > > > "SAPs that are ready to host per-service (but not yet activated) > > are > > > identified by the "service-status" set to "ietf-vpn-common:op- > > down"." > > > > But how do you distinguish between a SAP that hasn't been > > provisioned yet to a service vs a SAP that has been provisioned > > but the service is down? E.g., trying to find a free SAP just by > > looking for a SAP with a service-status of op-down doesn't appear > > to be sufficient on its own. > > [Med] A SAP that is not provisioned yet will have a sap-status=down, while > the 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 interface is down, then the sap-status would also be down? Hence, 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 Network > > Model: > > > > Node Filter > > > > > > > > > > [Med] Please note "Simple" in the title :-) > > > > OK, noted. ;-) > > > > > > > > > > > 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? > > > > > > [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 is > > listed 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 > to > host 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 obvious > > that it is actually either of those. I.e., really it is just a > > parent to sub-interfaces that represent the VPLS and L3VPN SAPs. > > [Med] These SAPs fall under: > > 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. > > > > > Hence, I was asking whether you considered putting GE0/6/1 into a > > different service/sap list (e.g., of service-type "sap-parent"), > > or similar. This would mean that the interface would be listed > > only once rather than under both VPLS and L3VPN. > > [Med] We are listing them per service because some interfaces may be > restricted to specific services. In the example, it happen that this > interface is > ready 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, it > > > > feels slightly strange to me to have GE0/6/4 listed under both > > l3vpn > > > > and vpls SAP lists. > > > > > > [Med] Actually there are attached to distinct sub-interfaces: > > > > So, my question is really whether, in this case, GE0/6/4 is > > actually 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 otherwise > we can't display where a service can be delivered unless a child SAP is > explicitly instantiated. > > > > > Possibly adding the "ready-child-sap" resolves this ambiguity. > > [Med] Agree. > > > Possibly, I would have a chosen a different name and description > > for this leaf (e.g., "sap-parent") that indicates that this node > > can act as a parent to other SAPs. > > > > > > > > > > Also, let us assume that, for > > > the 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 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: > > > > > > > > > > > > > > > (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? > > > > > > > > > > [Med] Changed to "future YANG modules (including future > > revisions of > > > the YANG model defined in this document)" > > > > Okay. > > > > > > > > > > > > > > > > > > > > > > (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. > > > > > > > > > > [Med] Given that this is used for correlation purposes, the > > value > > > enclosed in peer-sap-id is useful when it is known to the peer. > > > Typically, that value will be indicated as the service delivery > > point. 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 the > > peer sap id would actually be (or otherwise all the "peer_sap_id" > > names would collide). Perhaps this example is an exception to the > > rule, but then that would be worth highlighting in the text that > > describes the example. > > > > > > [Med] Fair. I added the following: > > " This identifier may or may not be the same as the SAP identifier used in the > peer's configuration. Note that the use of identical identifiers eases > correlation 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
