RFC 7769

Media Access Control (MAC) Address Withdrawal over Static Pseudowire

📅 published February 2016, from ietf

RFC 7769: Media Access Control (MAC) Address Withdrawal over Static Pseudowire ✨

okay bestie, so this is an IETF doc (the Internet Engineering Task Force 🌸) and it's RFC 7769 💅

  • Category: Standards Track, so it's a real protocol spec 🔥
  • Date: February 2016 📅
  • ISSN: 2070-1721
  • Authors: S. Sivabalan and S. Boutros (Cisco Systems, Inc.), H. Shah (Ciena Corp.), S. Aldrin (Google Inc.), and M. Venkatesan (Comcast) 🫶
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🦋

Abstract

okay so this doc is about a way to signal MAC address withdrawal notifications over a pseudowire (PW) Associated Channel (ACH) 🎀 Why does that matter? Because it's useful when statically provisioned PWs are deployed in a Virtual Private LAN Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment. It's giving network engineering, periodt ✨

Status of This Memo

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 5741 📚

info about the current status of this doc, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7769 💜

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully, bestie, because they explain your rights and restrictions for this document 🙈 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚠️

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  MAC Withdraw OAM Message  . . . . . . . . . . . . . . . . . .   4
4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  4.1.  Operation of Sender . . . . . . . . . . . . . . . . . . .   6
  4.2.  Operation of Receiver . . . . . . . . . . . . . . . . . .   7
5.  Security Consideration  . . . . . . . . . . . . . . . . . . .   8
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
  6.1.  MPLS G-Ach Type . . . . . . . . . . . . . . . . . . . . .   8
  6.2.  Sequence Number TLV . . . . . . . . . . . . . . . . . . .   8
7.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction ✨

okay so there's already an LDP-based MAC address withdrawal mechanism in [RFC4762] 💖 It removes dynamically learned MAC addresses when the source of those addresses can't forward traffic anymore. It works by sending an LDP Address Withdraw Message with a MAC List TLV that has the MAC addresses to be removed, and it goes to all the other Provider Edge nodes over the LDP sessions 🚀 [RFC7361] then describes an optimized version that only removes the MAC addresses that need to be relearned in H-VPLS networks. It also covers optimized MAC withdrawal operations in PBB-VPLS networks 🌸

now here's the plot twist 🙈 a PW can be signaled through LDP, or it can be statically provisioned. with a static PW, you can't use the LDP-based MAC withdrawal mechanism. this is kind of like the problem and solution in [RFC6478], where a PW OAM (Operations, Administration, and Maintenance) message was introduced to carry the PW status TLV over the in-band PW Associated Channel 🦋 In this document, we use a PW OAM message to withdraw MAC address(es) that were learned over a static PW. slay 👑

so MAC withdraw signaling for static PWs reuses two big ideas:

  • in-band signaling mechanisms, the ones static PW status signaling already uses, and
  • MAC withdrawal mechanisms, the ones described in [RFC4762] and [RFC7361].

real talk though, MAC withdraw signaling is a best effort scheme 😭 The goal is to speed up network convergence by cutting down on blackholes caused by PW failover for protected PWs. this protocol deals with the possibility of losing the MAC withdraw signal because of network congestion, but it doesn't guarantee delivery. LDP-based MAC withdraw signaling doesn't guarantee it either 💅 If the MAC withdraw signaling never reaches its target, traffic still recovers. the fallbacks are MAC re-learning from bi-directional traffic or, as a last resort, aging out MAC addresses when no frames come from the sources, and then traffic resumes over the new PW path 🌈 Those fallbacks can cause temporary blackouts, but they don't make a network permanently unusable 🫶

2. Terminology 🎀

the following terminology is used in this document:

  • ACK: Acknowledgement for MAC withdraw message
  • LDP: Label Distribution Protocol
  • MAC: Media Access Control
  • MPLS: Multiprotocol Label Switching
  • PW: Pseudowire
  • PW OAM: PW Operations, Administration, and Maintenance
  • TLV: Type, Length, and Value
  • VPLS: Virtual Private LAN Services

also, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🧚

3. MAC Withdraw OAM Message 💜

okay bestie, so LDP gives reliable packet transport for control packets on dynamic PWs 💫 Static PWs are different. they rely on retransmission and acknowledgments (ACKs) for reliable OAM packet delivery, as described in [RFC6478] 🙈 The proposed MAC withdrawal solution for static PWs also relies on retransmissions and ACKs. however, an ACK is mandatory 🔥 A given MAC withdrawal notification gets sent as a PW OAM message. the sender retransmits that message a configured number of times when there's no ACK response for the sequence-numbered message 🍓 The receiver removes the MAC address(es) for that sequence-numbered MAC withdraw signaling message and sends back the ACK response. if a message with the same or a lower sequence number shows up, the receiver responds with an ACK but doesn't remove any MAC addresses, because that's just a repeat 💅 And yes, a new TLV was defined to carry the sequence number 🌟

the format of the MAC address withdraw OAM message is shown in Figure 1 ✨ The MAC withdraw PW OAM message follows the same guidelines as [RFC6478]. that means the first 4 bytes of the OAM message header are followed by a message-specific field and a set of TLVs relevant to the message 🦋 Here's the big rule: the MAC withdrawal PW OAM message isn't refreshed forever, so a MAC address withdraw OAM message MUST contain a "Sequence Number TLV". if it doesn't, the entire message gets dropped 😭 It MAY also contain the MAC Flush Parameter TLV defined in [RFC7361] when static PWs are deployed in H-VPLS and PBB-VPLS scenarios 🌸 Last thing for the sequence-number TLV: its first 2 bits are reserved, so they MUST be set to 0 on transmit and ignored on receipt 🧚

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|   Reserved    |  MAC Withdraw OAM Msg (0x28)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           |  TLV Length   |A|R| Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Res|   Sequence No. TLV (0x1)  |  Sequence Number TLV Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         MAC List TLV                          |
   ~                MAC Flush Parameter TLV (optional)             ~
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: MAC Address Withdraw PW OAM Packet Format 🎀

in this section, the MAC List TLV and the MAC Flush Parameter TLV are collectively called "MAC TLV(s)" 🌈 The definition and processing rules for the MAC List TLV are described in [RFC4762], and the matching rules for the MAC Flush Parameter TLV are governed by [RFC7361] 💜

okay, two lengths to know 📏 "TLV Length" is the total length of all TLVs in the message, and "Sequence Number TLV Length" is the length of the Sequence Number field 🫶

next, the A-bit 🦋 It's a single bit that a receiver sets to acknowledge that it received and processed a MAC Address Withdraw OAM Message. in the acknowledge message, with the A-bit set, the MAC TLVs are excluded 💅

and the R-bit 🔥 It's also a single bit, and the sender sets it to request a reset of the sequence numbers. the sender does that when the pseudowire has restarted and has no local record of previous send and expected receive sequence numbers 🍓

one more rule: the Sequence Number TLV MUST be the first TLV in the message 👑

so here's why the sequencing matters 🧚 The lack of a reliable transport protocol for in-band OAM means you need a sequencing and acknowledgement scheme, so the receiver can tell newer messages apart from retransmitted older ones ✨ [RFC4385] covers the details of sequence-number handling, including overflow detection for a Sequence Number field that's 16 bits wide. this document reuses that same scheme, with two exceptions:

  • the Sequence Number field is 32 bits in size.
  • overflow detection is simplified: a sequence number that exceeds 2,147,483,647 (0x7FFFFFFF) is treated as an overflow and reset to 1 🌸

4. Operation 🌟

this section explains how the initial MAC Withdraw OAM Messages get sent and retransmitted. it also covers how those messages are processed and how retransmitted messages are identified 💖

More of this is coming in part 2 🫶

4.1. Operation of Sender ✨

okay bestie, every PW has its own counter 🧮 that keeps track of the sequence numbers on the MAC withdrawal messages it sends. Whenever a node sends a new set of MAC TLVs, it bumps the transmitted sequence-number counter and stuffs the new number into the message 💅. The transmit sequence number starts at 1 at the onset, after the wrap, and after a sequence number reset request is received. So the transmit sequence number is 2 in the first MAC withdraw message sent after it got initialized to 1 🌸.

The sender waits for an ACK from the receiver within a time interval we call "Retransmit Time" ⏰. That can be a default (1 second) or a configured value. If the ACK doesn't show up in time, the sender retransmits with the same sequence number as the original. The retransmission MUST cease when an ACK is received. To avoid endless retransmissions when no ACKs are coming back, a method of suppressing retransmissions MUST be implemented 🙅. A simple, well-used approach is to stop after a small number of transmissions. When there's no ACK, a one second retransmission with two retries is RECOMMENDED 💖. But the interval and the number of retries are a local matter with no interworking issues, so the operator MAY configure different values 🎀. Alternatively, an increasing backoff delay with a larger number of retries MAY be implemented to help with scaling issues 📈. None of these methods cause interworking problems, but the implementer must be mindful not to cause network congestion. They must also take into account that the decaying value of the delayed MAC withdraw signaling matters against possible relearning due to bidirectional traffic or MAC timeout 😭.

During retransmission, if a new MAC withdraw message with an updated sequence number needs to be sent, retransmission of the older unacknowledged withdraw message MUST be suspended, and retransmit time for the new sequence number MUST be initiated 🔁. Basically, a sender only runs retransmission logic for the most recently sent withdraw message for a given PW.

Now the tricky bit 🥲. If a pseudowire gets deleted and re-added, or the router restarts with configuration, the local node may lose track of the sequence number it sent before. That's a problem for the remote peer, because it will keep ignoring MAC withdraw messages with lower sequence numbers. So it's desirable to reset the sequence numbers at both ends of the pseudowire. The reset R-bit is set in the first MAC withdraw to tell the remote peer to reset its send and receive sequence numbers. The R-bit must be cleared in subsequent MAC withdraw messages after the acknowledgement is received ✨.

4.2. Operation of Receiver 🫶

Each PW has a register that keeps track of the expected sequence number of the MAC withdrawal message. It starts at 1. Whenever a MAC withdrawal message comes in and its sequence number is greater than the value in the register, the MAC addresses in the MAC TLVs get removed and the register is updated with the received sequence number. The receiver sends an ACK with the same sequence number as the received message 💌.

If the sequence number in the received message is smaller than or equal to the value in the register, the MAC TLVs are not processed. Still, an ACK with the received sequence number MUST be sent as a response 🙏. The receiver treats the ACK as an acknowledgement for all the MAC withdraw messages sent up to the sequence number in that ACK, and then it stops retransmission 🛑.

The handling of the sequence number is described in Section 3 🧠.

A MAC withdraw message with the R-bit set MUST be processed by resetting the send and receive sequence numbers first 🔄. The rest of the MAC withdraw processing happens as described above. The acknowledgement is sent with the R-bit cleared 🌈.

5. Security Consideration 🔐

Okay, this part is serious business 😤. The security measures described in [RFC4447], [RFC5085], and [RFC6073] are adequate for the proposed mechanism. So those are the protections this mechanism leans on, and the spec says they're good enough for it 🛡️.

6. IANA Considerations 📋

6.1. MPLS G-Ach Type 🦋

IANA has assigned a new channel type (0x0028) from the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry. The description of the new channel type is "MAC Withdraw OAM Message" 💜.

6.2. Sequence Number TLV 🧚

IANA has assigned a new TLV Type (0x0001) from the existing LDP "TLV Type Name Space" registry. The description for the new TLV Type is "Sequence Number TLV" ✨.

7. Normative References 📚

Authors' Addresses 💌

Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario  K2K 3E8
Canada

Email: msiva@cisco.com


Sami Boutros
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA  95134
United States

Email: sboutros@cisco.com


Himanshu Shah
Ciena Corp.
3939 North First Street
San Jose, CA  95134
United States

Email: hshah@ciena.com


Sam Aldrin
Google Inc.

Email: aldrin.ietf@gmail.com


Mannan Venkatesan
Comcast
1800 Bishops Gate Blvd
Mount Laurel, NJ  08075
United States

Email: mannan_venkatesan@cable.comcast.com
📦 where this page comes from