Hi, James. My email earlier this year to NANOG questioned using BFD through a "how far can I turn this knob" lens, which I got great feedback to "don't do that", but look into OAM instead, and here we are. My use case is pretty specific at the moment — frame loss measurement, reporting, alerting, mitigation — for single-segment L1 or L1.5 links, or L2VPN links that are provided by someone else and I don't see underneath the abstraction. Or put another way, my two ends of a link can already signal an actual link loss but are blind to losses or corruption of individual frames. Something that reads like link synthetic testing is what gets my attention.
That's a great page, thanks for the URL and for the tips below! I'm absorbing anything I can to lean into the right direction, and I particularly find the "Present in IEEE802.1ag" tagging helpful to understand the standards' overlap. The part of your page that jumps out at me is "Ethernet Frame Loss Measurement (ETH-LM)". I'm primarily looking for guidance on what others like you are doing, and stanza contribution helps a lot but isn't nearly as necessary as picking the right direction to point myself out of the gate. The feedback I've received does indeed seem to be leaning towards Y.1731 functionality. -dp From: James Bensley <lists+na...@bensley.me> Date: Wednesday, April 30, 2025 at 4:44 AM To: David Zimmerman <dzimmer...@linkedin.com>, nanog@lists.nanog.org <nanog@lists.nanog.org> Subject: Re: [NANOG] OAM and multiple choice questions -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Saturday, 19 April 2025 at 02:57, David Zimmerman via NANOG <nanog@lists.nanog.org> wrote: > Hi, all. A few months ago, I got really good guidance here to pursue OAM > instead of trying to use BFD in unnatural ways. I've been reaching out to my > vendors and through various searches, since the OAM space is wholly foreign > to me, and I'm currently on four different paths: > > > * IEEE 802.1aghttps://www.ieee802.org/1/pages/802.1ag.html now part of IEEE > 802.1Q-2022 CFM > > * IEEE > 802.3ahhttps://www.ieee802.org/21/doctree/2006_Meeting_Docs/2006-11_meeting_docs/802.3ah-2004.pdf > Ethernet OAM (aka Link OAM) > > * ITU-T Y.1731https://www.itu.int/rec/T-REC-Y.1731 OAM functions and > mechanisms for Ethernet based networks > > * MEF > 17https://www.mef.net/resources/mef-17-service-oam-framework-and-requirements/ > Service OAM Framework and Requirements Hi David, I was working on OAM stuff until circa 3 years ago, I made some notes comparing the different technologies you mentioned here: https://null.53bits.co.uk/page/ethernet-oam-and-cfm-standards You didn't say what your goal is (or maybe I missed it?). I was working for a service provider, providing wholesale point-to-point Layer 2 connectivity. This meant p2p pseudowires, and/or multi-segment pseudowires. We wanted to check the one way latency, two way latency, and packet loss of the service, and in the case of multi-segment pseudowires check this e2e, and for each segment. We also wanted to provide link-loss forwarding for the services. Finally, we wanted to allow our customers to also use CFM over our service, so we used levels 0-3 internally, and passed levels 4-7 transparently over the L2 service. If this is also your goal, you want Y.1731 (some vendors still call it IEEE 802.1ag even though they implement features not in IEEE 802.1ag, Y.1731 is kind of a superset of IEEE 802.1ag + fault management features). If this is you goal, I don't have any Juniper configs I can share with you, but a tip; we had this running over 3 different vendors, and they mixed the terminology quite a bit (new at ten, inter-op is tricky, shocking!). We tested it extensively so it was all definitely working but, as an example, the A end of a pseudowire was using vendor A, and the B end was using vendor B; on one end we configured a down MEP, and the other end an UP MEP, which was just plain wrong for our topology, but if we configured the same at both ends the CFM session wouldn't come up. We made lots of packet captures and opened TAC cases, and eventually found the magic config needed to get interop working. Some vendors acknowledged bugs which were fixed in later software releases, but that was of no use to us because, that would mean truck rolling everything vs sticking with our working but-slightly-misleading config (which was well documented anyway). So if my goals are/were similar to your goals, you want IEEE 802.1ag/Y.1731. IEEE 802.3ah is more for single physical segment monitoring and testing, we wanted L2 VPN testing, not single segment testing. As for MEF, we didn't look into this because we had no desire to be MEF certified. I hope that helps someone. Cheers, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJoEgzmCZCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3Jn5LQqSxSUCOfZrb+H1Wr9smh45mZfTB9G+hFA hOqJwG8WIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAIkgP+gIpvThyV/lOrzMu 5UxE5K7gxPyleAIb8pD4Jq9NNC20sXNhwIUykGBXNHWJpLLpoFOZFW1S3n4V y5DZMpVjhzQeFbdSq5P7C23RsPr8udm8W1gLjSNxFu+6rjPmrgQfjNLuW3Ud BflnXrjEfoxJk/TVTbAt6qiH6PegCs12sMZNbyUD9DuY/gxh74lNi+nP8wxV R9q20v3Z9hh3Dn5Ks8MWrl/7QAekUni3GJEmQgzvPfiNBkudXB0ChADaiAIF 8GeaR8qFnvubh0ZKZdciaphEnnNnRtHfkNrRFfk1ckdA2fI1qLaFZQ203h3S nmwVbfXCjxvKxwxU2QhdKMeI7UUK8NXLdK+PWlCm3fFO/RTUNhjy93z8jhn+ p0Hhk0mNZdhUPGj8bYDFPUHmpn7RXwgkV4+1iKI/dhCBvrha2UL1cRUC4eTF EARS/L13R9y9CDZ7akSt/t/z9ZDvf6jfcHeVEoiM50OtCLJQr6bQB+fMb6Fd DFvPZL9JHp7tXYNT0qeHm3XQN1Jsbyk+AfSZ5UPD1cE48uv86LVguvk4TZ4t Ohhqf2hNxacb8j0bJ3bISGPysxXbDNn85HzXex7tN2+cSHrEm36NzEsonx10 SDi2v1gUtvY8nTa1yoWmiQu6FZ/yHQmA1HUxspbC5OGhrjg2ACj9Cz9x3sgV UC6XUpBQ =JNlk -----END PGP SIGNATURE----- _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DT2VGXZOHJAQCEUOL72G5YCMQRC5ISF4/
