Hi Adrian, Thanks for the meticulous review. Much appreciated.
You may track a first set of proposed changes at: https://tinyurl.com/sap-latest. Let me know is more is needed. Please more context see inline. Cheers, Med > -----Message d'origine----- > De : Adrian Farrel <[email protected]> > Envoyé : jeudi 7 juillet 2022 19:43 > À : [email protected] > Cc : [email protected] > Objet : Document shepherd review of draft-ietf-opsawg-sap > > Hi, > > I am your document shepherd for this journey. > > Thanks for your work on the document so far, this is my review of > your draft. If you could work on updates or responses, I will > continue with the process of the shepherd write-up. > > Hoping this gives you enough time to post an update before the > IETF-114 lock-down. > [Med] Thanks. > Best, > Adrian > > === > > idnits points out there is a non-ASCII character in the reference > entry for [MEF17] [Med] I made some changes in the xml file. I hope this is fixed. > > --- > > What is a "network YANG model"? The only places this is used are: > - The title > - The running head > - The reference entry in the revision clause > > --- [Med] The intent was to reflect in the title this is a "network model" as per RFC8969. To avoid confusing readers not familiar with all these subtleties, I removed the mention from the title (and then reflected this in the reference and abbrev). > > Section 1 > > For example, this concept is > used to decide where to attach and, thus, deliver the service > in the > Layer 3 VPN Service Model (L3SM) [RFC8299] and the Layer 2 VPN > Service Model (L2SM) [RFC8466]. It can also be used to > retrieve > where services, such as the Layer 3 VPN Network Model (L3NM) > [RFC9182] and the Layer 2 VPN Network Model (L2NM) > [I-D.ietf-opsawg-l2nm], are delivered to customers. > > This is a bit confusing. I don't think L3NM and L2NM are services. > This just needs a bit of a tweak: L3SM and L2SM describe services; > L3NM and L2NM are used to derive the configuration information for > the network to enable delivery of the services in the SMs. So you > could change the second sentence to read: > > It can also be used to retrieve > where such services are delivered to customers through the > network > configuration described in the Layer 3 VPN Network Model (L3NM) > [RFC9182] and the Layer 2 VPN Network Model (L2NM) > [I-D.ietf-opsawg-l2nm]. > [Med] You got the intent :-) Fixed. Thanks. > --- > > Section 1 > > You have... > > Multiple service types can be associated with a given network. > Whether a SAP topology is dedicated to a specific service or > shared > among many services is deployment specific. This document > supports > both deployment schemes. > > The first sentence says "multiple service types" but the second > sentence is about "many services". Maybe... > > A network may support multiple services, potentially of > different > tyoes. Whether a SAP topology is dedicated to services of a > specific > service type, an individual service, or shared among many > services of > different types is deployment specific. This document supports > all > of these deployment schemes. > [Med] Works for me. > --- > > Use of optional plural(s). > > It's generally better style to use the plural when you mean "one > or more plurals" because one is just a special case of many. > [Med] fixed what I think is appropriate. > --- > > I think some more clarity is needed around the discussion of UNI > and NNI reference points. In RFC 6215 the UNI is situated between > the UNI-C and UNI-N, but which of these is the SAP? Similarly, > there are two end-points associated with the NNI. > > I think probably you intend the network side in both cases per > Figure 4. > [Med] Yes; see the mention about "customer-facing interfaces". Added this NEW text to be more explicit: NEW: Such interfaces are referred to as UNI-N (User-to-Network Interface, Network side) [RFC6215]. > Maybe this can go into the short definition of the SAP in Section > 2. > > --- > > The depiction of the Abstract Topology in Figure 3 and the text > above it is *a* way of looking at an abstraction, but I think the > user of the topology also has some expectation of the connectivity > between the PEs. > Perhaps you are assuming that this is a full mesh in all cases, > but I am not convinced that that would always be the case. So you > should probably represent the abstraction in one of the ways > talked about in RFC 7329. > > This is probably not substantially different from what you > intended. You could modify the abstraction through a virtual node, > virtual network, or virtual link model. That would lead you to one > of these... > > .---------. .---------. > | PE1 |----------| PE2 | > '---------'\___ /'---------' > | __\___/ | > | / \____ | > .---------./ \---------. > | PE3 |----------| PE4 | > '---------' '---------' > > > .---------. .---------. > | PE1 | | PE2 | > '---------'\ /'---------' > \.----./ > | VN | > /'----'\ > .---------./ \.---------. > | PE3 | | PE4 | > '---------' '---------' > > > .---------. .---------. > | PE1 | | PE2 | > '---------'\ /'---------' > \------/ > ( ) > ( ) > ( ) > /------\ > .---------./ \.---------. > | PE3 | | PE4 | > '---------' '---------' > [Med] Went with the last one for the abstract figure. > --- > > "setup" > > Verb : to set up > Noun : the setup > [Med] ACK. > --- > > I don't object to the model you are showing for where service is > provided and therefore the demarcation between customer and > provider. > But, as noted in draft-ietf-teas-network-slices, there may be a > number of options including: > - the CE is operated by the provider and the SAP is inside the CE > - the SAP is an exit port of the CE > - the SAP is a port on the PE or virtual channel on the AC > - the SAP is within the PE > > Not sure there is anything you need to do about this unless > something springs to your mind when you read it. [Med] Slicing was exactly what motivated the careful wording in the definition of SAP: Service Attachment Points (SAPs): An abstraction of the network reference points (e.g., PE side of an AC) where network services ^^^^^ can be delivered and/or being delivered to customers. I also changed the title of Section 3 to "Sample SAP Network Model Usage" to be clear this is just one main use, but other usages are. > > --- > > Section 4 > > Also, the SAP is not a tunnel termination point (TTP) (Section > 3.6 of > [RFC8795]) nor a link. > > A very helpful clarification. > > It's a bit orphaned where it is in Section 4. Shouldn't it be > located with the definition of SAP? > [Med] It is positioned here as this section is about clarifying the relationship with other models. I prefer to leave it here. Thanks. > --- > > Section 4 > > Advanced low-level interface-specific data nodes are not > exposed in > the SAP model. Filters based on the interface identifiers > listed in > the SAP model can be used together with dedicated device models > to > set or get such data. > > This paragraph, on the other hand, doesn't mean so much to me. Not > sure what an "advanced low-level interface-specific data node" is. [Med] This is to say that the model does not intend to be used as an alternative to manage interfaces. The ids in the SAP can be used to build filters as per rfc6241.html#section-6 + appropriate device modules to set/get such advanced data. Tweaked the text a little bit. Hope this is better: Advanced interface-specific data nodes are not included in the SAP model. The interface identifiers listed in the SAP model can be used as filters to set or get such data using device models (e.g., [RFC7224]). > > --- > > I'm not sure I'm comfortable with the list of service types in the > identityref service-type. Two questions spring to mind: > - what happens when new service types are invented? [Med] A new value will be defined (including proprietary ones). We do already have the following: "Other service types can be defined in future YANG modules, if needed." > - why do we need this? [Med] The value of having a list of identities in the spec is to make sure that consistent ids are used by implementations for these services rather than going with proprietary ids. It will be straightforward, for example, to map SAP information with the appropriate network configuration as the same service type is used in both models. This is at least the case for L2/L3 VPN: These service types build on the types that are already defined in [RFC9181] and additional types that are defined in this document. Added this NEW text: | Leveraging the service types defined in [RFC9181] is meant to | ease the correlation between the SAP topology and the | corresponding network modules that used to provision a specific | service. > > The second question might be answered by wanting to advertise > multiple SAPs to the customer but needing the customer to be able > to work out which SAPs support which services. Is that it? [Med] This can be used to map a service request with the underlying capabilities and see if a requested service scope can be accommodated by the network. To handle such an order, the service orchestrator can make queries by setting the filter as a function of the requested service type/scope. As this is deployment/implementation-specific, we only provide the external expected behavior: Filters based on the service type can be used to access per-service SAP topology. > > --- > > I have a similar question about interface-type and encapsulation- > type. > What happens when new types come along? > > Should these and service-type be in an IANA-maintained module? [Med] For encapsulation-type, we are reusing what is already in RFC9181. For interface-type, we don't want to be specific as RFC7224 but expose the level of information that is useful for an orchestrator/controller. We do have a default value ("logical") if none of other ids fits. If for some reason, there is a need to define a specific value, then this is always possible in future modules that augments the SAP model (e.g., add a new leaf that is specific to that new type). Identities are used here to ease defining future values. _________________________________________________________________________________________________________________________ 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
