doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc7769.txt b/doc/rfc/rfc7769.txt
new file mode 100644
index 0000000..53a6fae
--- /dev/null
+++ b/doc/rfc/rfc7769.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      S. Sivabalan
+Request for Comments: 7769                                    S. Boutros
+Category: Standards Track                            Cisco Systems, Inc.
+ISSN: 2070-1721                                                  H. Shah
+                                                             Ciena Corp.
+                                                               S. Aldrin
+                                                             Google Inc.
+                                                           M. Venkatesan
+                                                                 Comcast
+                                                           February 2016
+
+
+  Media Access Control (MAC) Address Withdrawal over Static Pseudowire
+
+Abstract
+
+   This document specifies a mechanism to signal Media Access Control
+   (MAC) address withdrawal notification using a pseudowire (PW)
+   Associated Channel (ACH).  Such notification is useful when
+   statically provisioned PWs are deployed in a Virtual Private LAN
+   Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS)
+   environment.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7769.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 1]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to 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 are 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 2]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+1.  Introduction
+
+   An LDP-based MAC address withdrawal mechanism is specified in
+   [RFC4762] to remove dynamically learned MAC addresses when the source
+   of those addresses can no longer forward traffic.  This is
+   accomplished by sending an LDP Address Withdraw Message with a MAC
+   List TLV containing the MAC addresses to be removed from all other
+   Provider Edge nodes over the LDP sessions.  [RFC7361] describes an
+   optimized MAC withdrawal mechanism that can be used to remove only
+   the set of MAC addresses that need to be relearned in H-VPLS
+   networks.  [RFC7361] also describes optimized MAC withdrawal
+   operations in PBB-VPLS networks.
+
+   A PW can be signaled via the LDP or can be statically provisioned.
+   In the case of a static PW, an LDP-based MAC withdrawal mechanism
+   cannot be used.  This is analogous to the problem and solution
+   described in [RFC6478] where a PW OAM (Operations, Administration,
+   and Maintenance) message has been introduced to carry the PW status
+   TLV using the in-band PW Associated Channel.  In this document, we
+   use a PW OAM message to withdraw MAC address(es) learned via a static
+   PW.
+
+   Thus, MAC withdraw signaling for static PW reuses the following
+   concepts:
+
+      -  in-band signaling mechanisms used by static PW status signaling
+         and
+
+      -  MAC withdrawal mechanisms described by [RFC4762] and [RFC7361].
+
+   MAC withdraw signaling is a best effort scheme.  It is an attempt to
+   optimize network convergence by reducing blackholes caused by PW
+   failover for protected PWs.  The protocol defined in this document
+   addresses possible loss of the MAC withdraw signal due to network
+   congestion, but does not guarantee delivery, as is the case for the
+   LDP-based MAC withdraw signaling.  In the event that MAC withdraw
+   signaling does not reach the intended target, the fallback to MAC
+   re-learning due to bi-directional traffic or as a last resort aging
+   out of MAC addresses in the absence of frames from the sources, will
+   resume the traffic via new PW path.  Such fallbacks would cause
+   temporary blackouts but does not render a network permanently
+   unusable.
+
+
+
+
+
+
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 3]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+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
+
+   In addition, 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
+
+   LDP provides reliable packet transport for control plackets for
+   dynamic PWs.  This can be contrasted with static PWs that rely on
+   retransmission and acknowledgments (ACKs) for reliable OAM packet
+   delivery as described in [RFC6478].  The proposed solution for MAC
+   withdrawal over a static PW also relies on retransmissions and ACKs.
+   However, an ACK is mandatory.  A given MAC withdrawal notification is
+   sent as a PW OAM message, and the sender retransmits the message a
+   configured number of times in the absence of an ACK response for the
+   sequence-numbered message.  The receiver removes the MAC address(es)
+   for a given sequence-number MAC withdraw signaling message and sends
+   the ACK response.  The receipt of the same or lower sequence-number
+   message is responded to with an ACK but does not cause removal of MAC
+   addresses.  A new TLV to carry the sequence number has been defined.
+
+   The format of the MAC address withdraw OAM message is shown in Figure
+   1.  The MAC withdraw PW OAM message follows the same guidelines used
+   in [RFC6478], whereby the first 4 bytes of the OAM message header are
+   followed by a message-specific field and a set of TLVs relevant for
+   the message.  Since the MAC withdrawal PW OAM message is not
+   refreshed forever, a MAC address withdraw OAM message MUST contain a
+   "Sequence Number TLV"; otherwise, the entire message is dropped.  It
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 4]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+   MAY contain the MAC Flush Parameter TLV defined in [RFC7361] when
+   static PWs are deployed in H-VPLS and PBB-VPLS scenarios.  The first
+   2 bits of the sequence-number TLV are reserved and 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 MAC Flush Parameter TLV are
+   collectively referred to as "MAC TLV(s)".  The definition and
+   processing rules of the MAC List TLV are described by [RFC4762], and
+   the corresponding rules of the MAC Flush Parameter TLV are governed
+   by [RFC7361].
+
+   "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.
+
+   A single bit (called "A-bit") is set by a receiver to acknowledge
+   receipt and processing of a MAC Address Withdraw OAM Message.  In the
+   acknowledge message, with the A-bit set, the MAC TLVs are excluded.
+
+   A single bit (called "R-bit") is set to indicate if the sender is
+   requesting reset of the sequence numbers.  The sender sets this bit
+   when the pseudowire is restarted and has no local record of previous
+   send and expected receive sequence numbers.
+
+   The Sequence Number TLV MUST be the first TLV in the message.
+
+
+
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 5]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+   The lack of a reliable transport protocol for the in-band OAM
+   necessitates a presence of sequencing and acknowledgement scheme so
+   that the receiver can recognize newer message from retransmitted
+   older messages.  [RFC4385] describes the details of sequence-number
+   handling, which includes overflow detection for a Sequence Number
+   field size of 16 bits.  This document leverages the same scheme with
+   the two exemptions:
+
+      -  the Sequence Number field is of size 32 bits.
+
+      -  overflow detection is simplified such that a sequence number
+         that exceeds 2,147,483,647 (0x7FFFFFFF) is considered an
+         overflow and reset to 1.
+
+4.  Operation
+
+   This section describes how the initial MAC Withdraw OAM Messages are
+   sent and retransmitted, as well as how the messages are processed and
+   retransmitted messages are identified.
+
+4.1.  Operation of Sender
+
+   Each PW is associated with a counter to keep track of the sequence
+   number of the transmitted MAC withdrawal messages.  Whenever a node
+   sends a new set of MAC TLVs, it increments the transmitted sequence-
+   number counter and includes the new sequence number in the message.
+   The transmit sequence number is initialized to 1 at the onset, after
+   the wrap and after the sequence number reset request receipt.  Hence
+   the transmit sequence number is set to 2 in the first MAC withdraw
+   message sent after the sequence number is initialized to 1.
+
+   The sender expects an ACK from the receiver within a time interval we
+   call "Retransmit Time", which can be either a default (1 second) or a
+   configured value.  If the ACK does not arrive within the Retransmit
+   Time, the sender retransmits the message with the same sequence
+   number as the original message.  The retransmission MUST cease when
+   an ACK is received.  In order to avoid continuous retransmissions in
+   the absence of acknowledgements, a method of suppressing
+   retransmissions MUST be implemented.  A simple and well-used approach
+   is to cease retransmission after a small number of transmissions.  In
+   the absence of an ACK response, a one second retransmission with two
+   retries is RECOMMENDED.  However, both the interval and the number of
+   retries are a local matter that present no interworking issues; thus,
+   the operator MAY configure different values.  Alternatively, an
+   increasing backoff delay with a larger number of retries MAY be
+   implemented to improve scaling issues.  Whilst there are no
+   interworking issues with any of these methods, the implementer must
+   be mindful to not introduce network congestion and must take into
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 6]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+   account the decaying value of the delayed MAC withdraw signaling
+   against possible relearning due to bidirectional traffic or MAC
+   timeout.
+
+   During the period of retransmission, if a need to send a new MAC
+   withdraw message with updated sequence number arises, then
+   retransmission of the older unacknowledged withdraw message MUST be
+   suspended and retransmit time for the new sequence number MUST be
+   initiated.  In essence, a sender engages in retransmission logic only
+   for the most recently sent withdraw message for a given PW.
+
+   In the event that a pseudowire is deleted and re-added or the router
+   is restarted with configuration, the local node may lose information
+   about the previously sent sequence number.  This becomes problematic
+   for the remote peer as it will continue to ignore the received MAC
+   withdraw messages with lower sequence numbers.  In such cases, it is
+   desirable to reset the sequence numbers at both ends of the
+   pseudowire.  The reset R-bit is set in the first MAC withdraw to
+   notify the remote peer to reset the 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 is associated with a register to keep track of the expected
+   sequence number of the MAC withdrawal message and is initialized to
+   1.  Whenever a MAC withdrawal message is received, and if the
+   sequence number on the message is greater than the value in the
+   register, the MAC addresses contained in the MAC TLVs are removed,
+   and the register is updated with the received sequence number.  The
+   receiver sends an ACK whose sequence number is the same as that in
+   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.
+   However, an ACK with the received sequence number MUST be sent as a
+   response.  The receiver processes the ACK message as an
+   acknowledgement for all the MAC withdraw messages sent up to the
+   sequence number present in the ACK message and terminates
+   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 number first.  The rest of
+   MAC withdraw message processing is performed as described above.  The
+   acknowledgement is sent with the R-bit cleared.
+
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 7]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+5.  Security Consideration
+
+   The security measures described in [RFC4447], [RFC5085], and
+   [RFC6073] are adequate for the proposed mechanism.
+
+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
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
+              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
+              Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
+              February 2006, <http://www.rfc-editor.org/info/rfc4385>.
+
+   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
+              G. Heron, "Pseudowire Setup and Maintenance Using the
+              Label Distribution Protocol (LDP)", RFC 4447,
+              DOI 10.17487/RFC4447, April 2006,
+              <http://www.rfc-editor.org/info/rfc4447>.
+
+   [RFC4762]  Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
+              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
+              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
+              <http://www.rfc-editor.org/info/rfc4762>.
+
+   [RFC5085]  Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
+              Virtual Circuit Connectivity Verification (VCCV): A
+              Control Channel for Pseudowires", RFC 5085,
+              DOI 10.17487/RFC5085, December 2007,
+              <http://www.rfc-editor.org/info/rfc5085>.
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 8]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
+              Aissaoui, "Segmented Pseudowire", RFC 6073,
+              DOI 10.17487/RFC6073, January 2011,
+              <http://www.rfc-editor.org/info/rfc6073>.
+
+   [RFC6478]  Martini, L., Swallow, G., Heron, G., and M. Bocci,
+              "Pseudowire Status for Static Pseudowires", RFC 6478,
+              DOI 10.17487/RFC6478, May 2012,
+              <http://www.rfc-editor.org/info/rfc6478>.
+
+   [RFC7361]  Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D.
+              Fedyk, "LDP Extensions for Optimized MAC Address
+              Withdrawal in a Hierarchical Virtual Private LAN Service
+              (H-VPLS)", RFC 7361, DOI 10.17487/RFC7361, September 2014,
+              <http://www.rfc-editor.org/info/rfc7361>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivabalan, et al.            Standards Track                    [Page 9]
+
+RFC 7769          MAC Address Withdrawal over Static PW    February 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+Sivabalan, et al.            Standards Track                   [Page 10]
+