Re: A question about RFC 6073
Alexander Vainshtein <[email protected]> Sun, 28 Jan 2024 11:57:58 +0000
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <PH0PR03MB6300BFBE99FEE6F8D58D0AD7F67F2@PH0PR03MB6300.namprd03.prod.outlook.com> |
Matthew and all, One more question about yet another undefined use case in RFC 6073<https://datatracker.ietf.org/doc/html/rfc6073>. The reference topology for this use case is shown in the diagram below. [cid:[email protected]] Suppose that initially: * All LSP session shown in the diagram have been successfully established * T-PE1 has sent a Label Mapping message to S-PE-1 that advertises some L1 for FEC-128 with the PW ID=100 * Consequently, S-PE1 (which, according to Section 7.2 of RFRC 6-73 takes a passive role) locally allocates label L2 and advertises it to S-PE2 in a Label Mapping message for FEC-128 with PW ID 200. Now my question: What should happen if the LDP session between T-PE1 and S-PE1 fails? Specifically, should S-PE1 send a Label Withdraw message for the label L2 and FEC-128 with PWID 200? My personal (and, probably, naïve) answer is that L2 should be withdrawn because, if LDP session between T-PE1 and S-PE1 were not established, S-PE1 would not receive the original Label Mapping message from T-PE1 and, therefore, would not advertise Label 2 for FEC-128 with PW ID 100 to S-PE2. My colleagues have observed at least one implementation of S-PE that simply does not do anything in this case. This does not look right to me - but I have not found any explicit definitions for handling this scenario in RFC 6073. Your feedback would be highly appreciated. Regards, and lots of thanks in advance, Sasha From: Alexander Vainshtein Sent: Tuesday, January 23, 2024 9:56 AM To: Bocci, Matthew (Nokia - GB) <[email protected]> Cc: [email protected]; [email protected] Subject: A question about RFC 6073 Importance: High 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
image001.emz
(application/octet-stream, 86.4 KB) - not displayed
image002.png
(image/png, 62.6 KB) - not displayed
oledata.mso
(application/octet-stream, 25.6 KB) - not displayed