Hi Benoît, Thank you for comments.
Please see inline. Cheers, Med De : OPSAWG <[email protected]> De la part de Benoit Claise Envoyé : jeudi 6 janvier 2022 17:57 À : Tianran Zhou <[email protected]>; [email protected] Cc : [email protected] Objet : Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00 Hi, I support the adoption. This is a much needed functionality, required to provide a layered view of the network (the service layer in this case). I like the fact it's based on the I2RS topology model. One clarification though. From that standpoint, and considering the architecture depicted in Figure 1, the goal of this document is to provide a mechanism to show via a YANG-based interface an abstracted network view from the network controller to the service orchestration layer with a focus on where a service can be delivered to customers. "can be delivered" or is delivered? [Med] We could actually say “can be (or is) delivered” but we didn’t at that stage of the document because “is delivered” will also require manipulating service-specific modules. I suggest we make this change: s/the goal of this document/a goal of this document In this figure, .---. |CE2| '-+-' | .---. .---. .---. .---. .-+-. +-|sap|-|sap|-|sap|-+ +-|sap|-------|sap|-+ | '---' '---' '---' | | '---' '---' | .---. .---. | | | |CE1+--+sap| PE1 | | PE2 | '---' '---' | | | | | | | +-------------------+ +-------------------+ +-------------------+ +-------------------+ | | | | | | | .---. .---. | PE3 | | PE4 |sap+--+CE5| | | | '---' '---' | .---. .---. .---. | | .---. .---. .---. | +-|sap|-|sap|-|sap|-+ +-|sap|-|sap|-|sap|-+ '---' '---' '-+-' '---' '---' '---' | | .-+-. .-+-. |CE3| |CE4| '-+-' '-+-' 1. Do we want to say that there are existing SAPs on PE routers, to which we can deploy new services? 2. Or do we want to say there is an existing service that connects CE2 to a specific SAP on PE2? [Med] Both are in scope. For the second one, we only indicate that an interface is currently used for the delivery of a service. This is inferred from the *-status data nodes. We will update the text to make this clearer in the next iteration. 1. implies that we have to list all the potential SAP types that "could" be delivered. And I don't know yet which service type will be configured. So I potentially need the full list of the "service-type" derived identities [Med] service-types can be controlled/restricted (e.g., capabilities of a PE, supported services in a network, etc.). 2. implies that only the existing configured SAP type needs to be documented [Med] Not necessary. A physical interface can also be exposed as a SAP even if no service is actually bound to it. The figures and texts points to 1., but 2 would be useful to me. So what's happening when a specific service type is configured on this CE2-facing SAP on PE2, the SAP-type goes a list to the unique configured SAP-type? In other words, can I do a filter on my topology for all the L3VPN configured SAPs? [Med] What we had in mind is to use a filter based on sap-type under network-types. However, I’m not sure this type of filtering is supported in NETCONF (presence, leaf-list). Of course, the filtering can be done locally at the orchestrator, but will need to think about this further and document the intended behavior. Thank you. Regards, Benoit On 1/5/2022 3:12 AM, Tianran Zhou wrote: Hi WG, I assume most of you are back to work. Hope you had a good holiday. As a follow up action after IETF 111, this mail starts a working group adoption call for draft-dbwb-opsawg-sap-00. https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/ This document defines a YANG data model for representing an abstract view of the provider network topology containing the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Please review and comment. We will conclude this adoption call after two weeks. Cheers, Tianran _______________________________________________ OPSAWG mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg _________________________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
