A question about RFC 6073

Alexander Vainshtein <[email protected]> Tue, 23 Jan 2024 07:55:59 +0000
Newsgroups gmane.ietf.pwe3
Message-ID <PH0PR03MB6300E75656EA7EA5D4E76B65F6742@PH0PR03MB6300.namprd03.prod.outlook.com>
Matthew and all,
I have a couple of questions about what looks to me as an undefined use case in RFC 6073<https://datatracker.ietf.org/doc/html/rfc6073>.

(These questions should be addressed to all the authors of this RFC, but the addresses that appear in the RFC seem to be not relevant anymore).

On one hand, Section 10.4 of this RFC states that "Pseudowire status signaling methodology, defined in [RFC4447], SHOULD be transparent to the switching point".   This suggests to me that S-PE does not have to be aware of the results of the PW Status negotiation by the T-PEs.

On the other hand, Section 10.1 of this RFC states that  " When a local fault is detected by the S-PE, a PW status message is sent in both directions along the PW".  This suggest that PW status messages should be sent even to T-PEs that do not recognize them and, therefore, would simply ignore them.

Now the questions:


  1.  Should S-PE really be aware of the results of the PW Status negotiation between the T-PEs?
  2.  If the answer to my 1st question is "Yes", should an S-PE that has detected a local fault still send PW Status messages in both directions of the PW?
  3.  If the answer to my 2nd question is "No", should an S-PE that has detected a local fault withdraw labels it has advertised in both directions of the PW instead of sending PW status messages (probably including appropriate SP-PE TLVs indicating the location of the fault)?

Your timely feedback would be highly appreciated.

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.

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals