Hi Sasha, all, (apologies for the delay to reply) (ccing onions) Agree with Joe.
That's said, there are few questions that might require some clarifications vs. the intended use/interpretation of the service ops status. That issue is tracked at: https://github.com/oscargdd/lxnm-bis/issues/4 or https://www.ietf.org/archive/id/draft-bg-onions-update-network-service-models-00.txt (Section 4.3). Cheers, Med De : Joe Clarke (jclarke) <[email protected]> Envoyé : lundi 11 août 2025 15:26 À : Alexander Vainshtein <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]>; [email protected]; [email protected]; [email protected] Cc : [email protected]; Pseudowire And LDP-enabled Services Discussion List <[email protected]> Objet : PW Operational Status in RFC9291 (was: Re: PW Operational Status in RFC 9251) As a contributor of opsawg (authors of 9291 can correct me), the scope of RFC9291 and RFC5601 are not the same. RFC5601 defines a device-level MIB module specifically for pseudowires. RFC9291 defines a network-level YANG module abstracting various L2VPN network services and is designed to be implemented on a network controller. Therefore, the oper-status is not specifically tied to a pseudowire class and not tied to a particular device-level implementation (i.e., it applies to the network-level L2VPN). The intent of YANG network and service data models is that they abstract capabilities to a customer-facing or network-facing portal/controller and ultimately rely on device-level interfaces (hopefully standards-based, device-level YANG data models, but maybe proprietary YANG data models or CLI) to do the configuration and perform the monitoring across the full service implementation. It would be up to the device-level pseudowire interface to provide the modeling and documentation that the PW-MIB has. Joe From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Sunday, August 10, 2025 at 07:27 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Pseudowire And LDP-enabled Services Discussion List <[email protected]<mailto:[email protected]>> Subject: [OPSAWG]PW Operational Status in RFC 9251 Dear authors of RFC 9291<https://datatracker.ietf.org/doc/html/rfc9291>, I have looked up the standard and found that it presumably mentions Operational Status of a pseudowire as oper-status without any clarifications and/or references, and, specifically, without any association with various indicators in the PW Status TLV. This is quite different from RFC 5601<https://datatracker.ietf.org/doc/html/rfc5601>, which explicitly provides such linkage as can be seen from the quoted text below: pwOperStatus OBJECT-TYPE SYNTAX PwOperStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the operational status of the PW; it does not reflect the status of the Customer Edge (CE) bound interface. It is set to down only if pwNotForwarding, psnFacingPwRxFault, or psnFacingPwTxFault indications are set in pwLocalStatus or pwRemoteStatus. It indicates 'lowerLayerDown' if the only reason for not being in the 'up' state is that either the outer tunnel or physical layer of the network side is in the 'down' state. All other states are declared based on the description of the PwOperStatusTC. " I wonder whether, from your POV, the quoted definition of the PW Operatonal Status is still applicable or not. Regards, and lots of thanks in advance, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. ____________________________________________________________________________________________________________ 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] To unsubscribe send an email to [email protected]
