Hi Alexander and Andy, Yes, very useful comments indeed !
Totally agree in case a “misconnection” is detected a downstream fault indication signal such as AIS or LF must be inserted, I meant to cover that but it somehow slipped through the cracks so far. Btw I would further propose to follow SDH/OTN where this is conditional on local configuration. SDH calls this TIMAISdis and OTN calls it TIMActDis. I will think about proper text to be inserted in https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-01#section-7.2.2 as well as draft-schmutzer-pals-ple-signaling and draft-schmutzer-bess-bitstream-vpws-signalling in furture revisions. On the topic of FEC-129 vs Endpoint-ID, I need some time to refresh my memory on FEC-129 and think about how all of this would tie back to meeting the user expectations … I will come back to this thread in the future Cheers Christian On 09.11.2023, at 15:59, Alexander Vainshtein <alexander.vainsht...@rbbn.com> wrote: Andrew hi! Very glad to hear from you! I have looked up Section 7 of RFC 4842<https://datatracker.ietf.org/doc/html/rfc4842#section-7>, and I fully agree that the draft should define equivalent behavior (where applicable) for both Private Line to PSN and PSN to Private Line directions. These actions are probably specific to each PLE type. In any case, the draft does not define any action on Endpoint-ID mismatch. My guess is that PW setup should fail in this case – Christian, can you please comment? (This would happen automatically if FEC-129 were used and mismatch between SAII and TAII occurs). If my guess is correct then Section 7.2.2 of the PLE draft<https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-01#section-7.2.2> requires that “the CE-bound NSP function MUST inject the appropriate native downstream fault indication signal” because failure to set up the PW means that the PW is not operationally UP. Regards, Sasha From: Andrew G. Malis <agma...@gmail.com<mailto:agma...@gmail.com>> Sent: Thursday, November 9, 2023 4:35 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: Christian Schmutzer (cschmutz) <cschm...@cisco.com<mailto:cschm...@cisco.com>>; p...@ietf.org<mailto:p...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> Subject: [EXTERNAL] Re: Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00 Christian and Sasha, Section 7 of RFC 4842 discusses the actions taken when you have trace mismatch conditions as well as other SONET/SDH-layer failures. Perhaps this text should be adapted to draft-ietf-pals-ple as well. Cheers, Andy On Thu, Nov 9, 2023 at 8:34 AM Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> wrote: Christian and all, Repeating the gist of my comments on the PLE Signaling draft<https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00> at the MPLS WG session in Prague today. I think that Endpoint-ID defined in Section 5.5. of this draft is not needed. If you want the endpoints of a PLE to be aware of the remote AC, you can use the generalized PWId FEC<https://datatracker.ietf.org/doc/html/rfc8077#section-6.2> a.k.a. FEC-129) for this purpose. I also think that your reference to Path Trace Identifier in OTN is not really accurate: 1. This construct has been already defined for SONET and SDH 2. Mismatch of Path Trace Identifier, if enabled, results in killing he traffic (generation of downstream AIS) in both SONET/SDH and OTN. a. I have not found any action on mismatch of Endpoint-IDs in the draft b. Mismatch of AII in FEC-129 would result in failure to establish a PW. Hopefully these notes will be useful. Regards, 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.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
