Hi all,
Please find below a follow-up to some questions raised in the meeting:
(1) Scott asked during the meeting whether the service type is a type or a
pointer to an instance of a service. I confirm that this is a type, not a
service instance. Service types are typically taken from RFC9181. That part is
covered in the I-D:
A node in the topology can support one or multiple service types
('service-type') among those listed under the 'sap-network'
container. A list of SAPs are then bound to each service type that
is supported by a given node.
Service instances of given service may be bound to the same or separate SAPs
having the same service type. For typical services such LxVPN, dedicated
sub-interfaces are used to demux these instances but the parent interface is
also exposed as a SAP as per the following:
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.
Note that a SAP may even host services of #types as per the following from the
draft:
The same SAP may appear under distinct service types. In such a
case, the same identifier is used for these service types in
association.
That's the reason why we do separate sap-status vs. service-status:
'service-status': Reports the operational status of service for a
given SAP. This information is particularly useful when many
services are enabled for the same SAP, but only a subset of them
are activated.
(2) Then, followed this comment from Rob:
==
Rob Wilton: Wouldn't you end up binding the sap against an sub-interface?
Med: not necessarily-please clarify
Rob: If you have multiple saps how are they modeled?
Med: I will check against sub-interfaces offline.
==
I confirm may first answer: not necessarily. For typical services such as
LxVPN, sub-interfaces are likely to be created for each service instance. All
these are exposed as separate SAPs, which may have their own characteristics,
especially these leafs:
+--rw attachment-interface? string
+--rw interface-type? identityref
+--rw encapsulation-type? identityref
+--rw peer-sap-id? string
However, the parent termination point that hosts these sub-interfaces is also
exposed as a SAP. That SAP does not have a sub-interface. We do cover that
aspect in the draft:
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.
The example depicted in Appendix B is useful to digest this aspect of SAP
modelling.
Cheers,
Med
_________________________________________________________________________________________________________________________
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
