[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Provider Provisioned VPN WG                    N. Finn      (Cisco)
Internet-draft                                 M. Seaman    (Consultant)
Expires: December 2002                         A. Smith     (Consultant)
                                               A. Romanow       (Cisco)

                           Bridging and VPLS

Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

     Copyright (C) The Internet Society (2002). All Rights Reserved.


     Layer 2 techniques based on IEEE 802.1Q bridges are in widespread
     use by Ethernet MAN Service Providers.  It is possible to implement
     the data plane functionality of Service Provider Backbone as
     described in the framework draft [ANDERSSON] using bridges as the
     Provider Edge (PE) equipment.  There are three small but
     significant changes to the [LASSERRE-VKOMPELLA] VPLS draft which
     would make the Service Provider Backbone much more compatible with
     a bridge-based PE implementation, and which would improve the
     efficiency of all L2VPN implementations.

Finn and others           Expires December 2002                 [Page 1]

Internet-Draft              Bridging and VPLS               21 June 2002

Table of Contents

     1.   Introduction . . . . . . . . . . . . . . . . . . . . . . .   2
     2.   Signaling the Need to Unlearn MAC Addresses  . . . . . . .   3
     2.1.   Requirement for Unlearning MAC Addresses . . . . . . . .   3
     2.2.   How Bridges Forget MAC Addresses . . . . . . . . . . . .   4
     2.3.   Improved L2VPN Flush Messages  . . . . . . . . . . . . .   5
     3.   Send Flush on Recovery, Not Failure  . . . . . . . . . . .   5
     4.   Independent vs. Shared Address Learning  . . . . . . . . .   8
            Acknowledgements . . . . . . . . . . . . . . . . . . . .   9
            References . . . . . . . . . . . . . . . . . . . . . . .  10
            Authors' Addresses . . . . . . . . . . . . . . . . . . .  10
            Full Copyright Statement . . . . . . . . . . . . . . . .  11

1.  Introduction

     A number of Ethernet Service Providers are currently building their
     networks using purely L2 technologies, based around bridges.  When
     such an L2-oriented network provider looks at the architecture of
     [ANDERSSON], the similarity of Provider Edges (PEs) and bridges is
     unavoidable, and the desirability of constructing a PE based on a
     bridge is attractive.  A bridge-based PE allows the Provider to
     make use of the extensive capabilities of the current generation of

     Trying to base a PE implementation on a bridge raises certain
     issues with the specification and implementation of L2VPNs which
     have not been addressed in the drafts, to date.  Resolving these
     issues requires some minor changes to [LASSERRE-VKOMPELLA]. These

     1.   Two new "forget MAC addresses" L2VPN control packets are

     2.   "Forget MAC addresses" L2VPN control packets should be sent
          when backup links become activated, not when links fail.

     3.   It must be possible to configure associations among L2VPN
          instances such that a group of L2VPNs share a single MAC
          address database in any given attached device, but different
          groups of L2VPNs use different databases.

     This present document assumes the validity of the [ANDERSSON] and
     [LASSERRE-VKOMPELLA] drafts.  We use the terminology of
     [ANDERSSON], borrowing from [LASSERRE-VKOMPELLA] and [SAJASSI] when

Finn and others           Expires December 2002                 [Page 2]

Internet-Draft              Bridging and VPLS               21 June 2002

     Sections 2 and 3 explain the need to have forms of the [LASSERRE-
     VKOMPELLA] flush message that are compatible with the operation of
     bridges, and the necessary timing of sending those messages.
     Section 4 describes a requirement to allow some L2VPNs to share a
     common MAC address database.

2.  Signaling the Need to Unlearn MAC Addresses

     The "flush" message of [LASSERRE-VKOMPELLA] is inadequate to the
     needs of bridges either serving as PEs or as part of an Access
     Network [ANDERSSON] in a Provider Network.  The two forms of the
     flush message are, "forget all MAC addresses in this list," and
     "forget all the MAC addresses you learned from me."  There is no
     way for a bridge to generate an accurate list of MAC addresses for
     the first message, and no circumstances under which a bridge would
     issue the second message.

     The following sub-sections describe the need for unlearning, how
     the two major spanning tree protocols handle the deliberate
     forgetting of MAC address information, and the bridge requirements
     for flush messages.

2.1.  Requirement for Unlearning MAC Addresses

     If bridges operate over Psuedo Wires (PWs) such that redundant PEs
     are provided to improve the availability of the Provider Network,
     then the possibility arises that changes in an Ethernet Service
     Provider's Access Network will require packets to take different
     paths through the Provider Backbone.  An obvious example is shown
     in Figure 1:

       +-------------+ .1Q +----------+ PW1  +----------+   +-------------+
       + PE-bridge 1 +-----+   PE 1   +------+   PE 3   +---+ PE-bridge 2 |
       +-+---------+-+     +--------+-+      +-+--------+   +-----------+-+
         | Ether    \          PW2 | Backbone /                   Ether |
         |           \ .1Q +--------+-+      /                          |
       Customer       '----+   PE 3   +-----'                      Customer
       Station A           +----------+ PW3                        Station B

          FIGURE 1:  Unlearning MAC addresses in L2VPN due to L2 changes

     In this diagram, we have five Provider bridges, PE-bridge 1 and 2,
     and PEs 1 through 3.  The PWs of one (data) VLPLS are shown.  Keep
     in mind, however that we are not using spanning tree to select
     among PWs; the PWs form a full mesh, and split horizon is used to
     prevent loops within the L2VPN.

Finn and others           Expires December 2002                 [Page 3]

Internet-Draft              Bridging and VPLS               21 June 2002

     Spanning tree may, however, be running over the whole network, in
     which case spanning tree Bridge Protocol Data Units (BPDUs) may be
     carried as ordinary multicast data over one or more of the PWs.

     Suppose that the normal path between stations A and B goes through
     PE 1.  PE 3 has learned this fact, and directs its packets destined
     for station A to PE 1.  If the link between PE-bridge 1 and PE 1
     fails, then it is possible that the redundancy/failover algorithm
     in use will select PE 2, rather than PE 1, to be the portal to the
     Backbone.  In that case, PE 3 needs to "unlearn" its association
     between MAC address A and PE 1.

2.2.  How Bridges Forget MAC Addresses

     The spanning tree algorithms in [802.1D] and [802.1w] provide two
     methods for notifying bridges when MAC address information needs to
     be unlearned.  The "classic" Spanning Tree Protocol, STP, defined
     in [802.1D] describe one way, and the new Rapid Spanning Tree
     Protocol (RSTP) in [802.1w] behaves another way.

     In STP, when a topology change occurs, notification of the change
     is transmitted to the root bridge, which in turn relays the fact to
     all bridges.  The notification is not directional; the root places
     all bridges in "topology change mode" for a certain length of time,
     then returns all bridges to normal mode.  While in topology change
     mode, all MAC address information is timed out over a much shorter
     period than is normally the case.

     In normal times, the default timeout period for MAC address
     information is five minutes.  During a topology change, that time
     shortens to a default value of 15 seconds.  This time is comparable
     to the time during which service may be interrupted by a topology
     change.  The shortened timeout period ensures that stale
     directionality information will not survive the topology change.
     Note that, if the MAC addresses were instantly forgotten, instead
     of timed out rapidly, a great deal of traffic otherwise unaffected
     by the topology change would be unnecessarily flooded.

     In RSTP, a Topology Change Notification (TCN) is initiated only by
     a bridge port that has just transitioned from standby to
     operational status.  It is generated only on that newly operational
     port, and is then relayed along the spanning tree by the other
     bridges.  Thus, RSTP TCNs have a direction of propagation, and
     bridges "behind" the new link do not receive it.  Since RSTP can
     converge in milliseconds after a topology change, receipt of a TCN
     causes a bridge to instantly forget many MAC addresses.  A bridge
     does not forget MAC addresses associated with the port on which the
     TCN was received; one can prove that the MAC address information on

Finn and others           Expires December 2002                 [Page 4]

Internet-Draft              Bridging and VPLS               21 June 2002

     that port cannot be affected by any topology change.

2.3.  Improved L2VPN Flush Messages

     To be consistent with bridges, the L2VPN learning and forgetting
     rules must be compatible with the bridge rules described in the
     previous section.  The two specific L2VPN messages required for
     full compatibility with all standard bridges are:
          v.IP 1.  STP TOPOLOGY CHANGE START/END.  Set the timeout
          period of all learned MAC addresses on this list of L2VPNs to
          this number of seconds.  This message is transmitted with a
          shortened timeout value at the beginning of a "classic" STP
          topology change event, and transmitted with the default
          timeout period after the event ends.

     2.   RSTP TOPOLOGY CHANGE.  Immediately delete all MAC address
          information on this list of L2VPNs except that information
          learned from the sender of this message.  (Note that this is
          exactly the opposite from the current "flush all you learned
          from the sender" message.)

     The first message, which is compatible with the old STP, is of
     questionable utility, simply because it is needed by a form of STP
     which takes 10s of seconds to converge after the failure or
     recovery of a node or link.  The Rapid Spanning tree converges much
     more quickly, and uses the second form.

     To the best of the authors' knowledge, these two actions are
     sufficient to meet the needs of all proprietary Layer 2
     failure/recovery protocols based on spanning tree.  If not,
     suggestions for additional actions are encouraged.

3.  Send Flush on Recovery, Not Failure

     In [LASSERRE-VKOMPELLA], a device that notices the failure of a
     non-PW link is required to transmit the flush message(s) over the
     Backbone.  It is much better to transmit the flush messages at
     recovery time, that is, when an alternate to the failed link
     becomes operational, or when a new link is added.  In brief, one
     reason is that frames are best flooded when there is a good chance
     that their destinations are reachable, and therefore will elicit
     the replies that will terminate the flooding.  The second reason is
     that link failures cannot reliably be detected, whereas recovery
     events are sure and certain.

     In RSTP [802.1w], it is the device that starts using the backup
     link that generates the flush message(s).

Finn and others           Expires December 2002                 [Page 5]

Internet-Draft              Bridging and VPLS               21 June 2002

         "backdoor" _________________________________
            link   /                                 \
               +--+-+     +----+  Y--+----+        +--+-+
               | B1 |-----| B2 |-----| B3 |........| B4 +--Z
               +----+  ___+--+-+     +--+-+,..   ..+----+
                     \/      |   ___/   |   : \ /    : (Backbone)
                     /\___   |  /       |   :  :     :
               +----+     +--+-+     +--+-+;../ \..+----+
           X --+ B5 |-----| B6 |-----| B7 |........| B8 |
               +----+     +----+     +----+        +----+

                 Figure 2: L2VPN Flush Messages

     In Figure 2, consider a PE B3 with some form of Ethernet
     connections on one side, and the Pseudowire world on the other
     side.  If that PE discovers that a link has gone down, say the
     B5-B2 link, the B2-B3 link, or the Y-B3 link, there are several
     possibilities for what can be wrong or right about learned MAC
     address information:

     1.   The link is permanently down.  Those MAC addresses will be
          unreachable for a very long time.

     2.   The link is momentarily down.  Those MAC addresses will again
          be reachable through the same link in a very short time.

     3.   The link is down, but a backup link to this same PE, carrying
          those same MAC addresses, will very shortly be activated.

     4    The link is down, but a backup link to another PE, carrying
          those same MAC addresses, will very shortly be activated.

     In all of these cases, forgetting the MAC addresses immediately
     upon failure of the link does not help anything, especially if
     there are a large number of them associated with the failed link.
     If the MAC addresses "never" come back, they will eventually time
     out and be deleted everywhere.  Assuming that the link was running
     at full speed when it failed, all of the traffic already in, queued
     for transmission to, or about to be sent by the user to the
     network, will be flooded throughout the L2VPN.  Furthermore, this
     burst of flooding is useless, as it will occur at the very moment
     when it is the least likely that the flooded frames can reach their
     destinations.  This means, of course, that the out-of-touch
     stations cannot respond to the flooded frames and put a stop the
     flooding.  The flooding continues until the upper layers decide to
     wait for responses.

     In fact, it is when a link transitions from backup to operational

Finn and others           Expires December 2002                 [Page 6]

Internet-Draft              Bridging and VPLS               21 June 2002

     status that MAC addresses can be profitably forgotten.  Unless or
     until an alternate path to the lost MAC addresses becomes
     available, the packets destined for those MAC addresses is best
     black-holed.  If the MAC addresses never come back, then in the
     usual case, the bridge MAC address timeouts are such that the upper
     layers will give up on the conversation before the bridges forget
     the MAC addresses and start flooding the doomed traffic.  If the
     MAC addresses do come back, then old information is deleted as the
     first thing, and the flooded frames have a good chance of reaching
     their (new) destinations.  This is why RSTP waits until a link
     comes up to generate a Topology Change Notification.  Only when an
     alternate path is available is there any reason to flood frames

     Looking at Figure 2, suppose that links B5-B2, B2-B3, and the
     Backbone PWs are the primary links between B5 and B4, and
     specifically that B5-B6 is kept in reserve.  In RSTP parlance, B5's
     port to B2 is a (forwarding) root port, and B5's port to B6 is a
     (discarding) alternate port.  If the B5-B2 link fails, B5's port to
     B6 becomes the forwarding root port, and a TCN is sent.  Note that,
     because of the direction of propagation of the TCN, B4 does not
     forget address Y, because that address cannot possibly have
     changed; the new link came up "behind" the Y-B3 connection.
     Interestingly, B3 does have to forget address Z, because it cannot
     know for certain that the "backdoor" link shown in the diagram has
     not come into use to deliver frames from Z via B1 and B2.  In other
     words, RSTP does not assume that it knows the global topology.
     However, any such needlessly flooded frames will reach their
     destinations and be answered, and so will very quickly be

     Many bridges treat MAC addresses attached to configured local
     access ports, rather than inter-bridge links, as sure knowledge.
     Those MAC addresses are not deleted from the owning bridge.

     If the device that brings up the new link knows what MAC addresses
     it is serving, perhaps by configuration, then the best solution is
     to transmit a "learn the following MAC addresses" control message.
     This is ideal, and is provided by [LASSERRE-VKOMPELLA].  In
     general, however, a bridge does not know this.

     One should also consider what happens if the failure occurs in a
     link not directly connected to the PE?  What happens if the PE is
     connected to a shared medium Ethernet, so that the loss of another
     device's connection is invisible to the PE?  (Shared media still
     exist, new ones such as packet rings are being created, and
     wireless hubs are very similar in nature.)  What happens if only
     one side of the connection gets a "glitch" and believes that the

Finn and others           Expires December 2002                 [Page 7]

Internet-Draft              Bridging and VPLS               21 June 2002

     link has momentarily gone down?

     The RSTP solution is known to handle all of these cases correctly.
     It would be better for any L2VPN solution to employ that same
     technique.  In other words:

     1.   As "classic" STP enters and leaves the topology change mode,
          the bridge responsible for transmitting that fact to the
          Backbone should also transmit the "accelerate timeouts" L2VPN
          control message for all affected L2VPNs.  {This is not needed
          if classic STP is not to be supported.)

     2.   When a "rapid" RSTP bridge transmits a TCN BPDU over the
          Backbone, it should also transmit the "forget all MAC
          addresses not learned from me" L2VPN control message for the
          Pseudowires associated with the affected spanning tree

     3.   When some L2 device not utilizing spanning trees, such as the
          PE-CLE of [SAJASSI], switches to a new PE, it should transmit
          a control message towards the new PE.  This message causes the
          PE to issue a "forget all MAC addresses not learned from me"
          L2VPN control message only for the L2VPNs connected to the
          affected PE-CLE.

4.  Independent vs. Shared Address Learning

     In order to be consistent with the current capabilities of [802.1Q]
     bridges, it must be possible to configure any number of L2VPNs
     either to use separate MAC address databases, as specified in
     [LASSERRE-VKOMPELLA], or to use the same MAC address database. If
     not, we remove a standard bridge capability that is not only
     expected by a significant fraction of the user community, but one
     which is actually more useful in the Ethernet Provider space than
     in the enterprise space.

     In particular, a bridge which is conformant to [802.1Q] can be
     configured, for any given pair of VLANs, to store those two VLANs'
     MAC address information in two different Filtering Databases
     (Independent VLAN Learning, IVL), or to use the same Filtering
     Database for both (Shared VLAN Learning, SVL).  (It also permits
     the user to specify "don't care", and let the bridge decide.)  That
     is, MAC addresses learned on one VLAN may or may not, according to
     the specific configuration of the bridge, be used to forward frames
     on another VLAN.  This fact has been utilized in a great many ways,
     by a number of bridge vendors and bridge customers, in order to
     implement a number of useful features.  It is a behavior that has

Finn and others           Expires December 2002                 [Page 8]

Internet-Draft              Bridging and VPLS               21 June 2002

     been in IEEE 802.1Q since 1998, and in various vendors' bridges
     long before that date.  It cannot be removed without a serious
     impact on the users of bridged LANs.

     Given that one VLAN in the Access Network is associated with one
     L2VPN, we are lead to the conclusion that two or more L2VPNs may be
     similarly configured to use either IVL or SVL.  In other words, two
     L2VPNs A and B may be configured such that a {MAC address, PW)
     association learned by a PE on L2VPN A is used when that PE
     transmits packets to a PW on L2VPN B.  Another way to phrase this
     is that bridges do not remember {MAC, VLAN-ID, port} triplets, but
     instead, remember {MAC, FID, port} triplets, where "FID" is the
     Filtering ID, identifying a Filtering Database.  The FID is derived
     from VLAN-ID through a statically configured mapping table.
     Similarly, L2VPN interfaces must learn {MAC, FID, PW} triplets
     instead of {MAC, L2VPN-ID, PW} triplets, by means of a configured
     L2VPN-to-Filtering-Database-ID table.

     A concrete example of Shared VLAN Learning is the "Spanning Tree
     Per Bridge" technique which is most useful in a ring of bridges.
     (This is a more common topology in Ethernet MAN Provider Networks
     than in enterprise networks.)  In a ring with one spanning tree,
     one link must be blocked, in order to prevent a closed forwarding
     loop.  Traffic between bridges on opposite sides of the blocked
     link must go the long way around the ring.  To avoid this
     inefficiency, the "Spanning Tree Per Bridge" technique employs n
     spanning trees, and splits each VLAN into a group of n VLANs, one
     for each spanning tree.  Each bridge associates itself with exactly
     one spanning tree, selected so that the blocked link of that
     spanning tree is near the opposite side of the ring.  Every frame
     it sends for a given VLAN group is sent only on the particular VLAN
     associated with that bridge's spanning tree.  Clearly, for this to
     work, all of the VLANs in one group must share the same Filtering

     If the user of this "Spanning Tree Per Bridge" technique is a
     customer of an Ethernet MAN Service Provider, purchasing multiple
     L2VPNs to make the connections between the customer's bridges, then
     the provider's L2VPNs must share their learned MAC addresses.


     The authors wish to thank Ali Sajassi, Joel Halpern, Steve Phillips
     and Adam Sweeney for their valuable suggestions, both technical and
     editorial, for correcting and improving this document, as well as a
     number of IEEE P802.1 voting members who reviewed it.

Finn and others           Expires December 2002                 [Page 9]

Internet-Draft              Bridging and VPLS               21 June 2002


     "PPVPN L2 Framework", draft-andersson-ppvpn-l2-framework-00.txt
     (Work in Progress)

     "Virtual Private LAN Services over MPLS", draft-lasserre-vkompella-
     ppvpn-vpls-01.txt (Work in Progress)

     "VPLS Architectures", draft-sajassi-vpls-architectures-00.txt (Work
     in Progress)

     "Information technology.  Telecommunications and information
     exchange between systems.  Local and metropolitan area networks.
     Common specifications.  Part 3: Media Access Control (MAC)
     Bridges", ANSI/IEEE Std 802.1D-1998.

     "IEEE Standards for Local and Metropolitan Area Networks: Virtual
     Bridged Local Area Networks", IEEE Std 802.1Q-1998.

     "IEEE Standard for Local and metropolitan area networks.  Common
     specifications Part 3: Media Access Control (MAC) Bridges.
     Amendment 2: Rapid Reconfiguration", IEEE Std 802.1w-2001.

Authors' Addresses

     Norman Finn
     Cisco Systems
     170 W Tasman Drive
     San Jose, CA 95134

     Phone: +1.408.526.4495
     Email: nfinn@cisco.com

Finn and others           Expires December 2002                [Page 10]

Internet-Draft              Bridging and VPLS               21 June 2002

     Mick Seaman
     160 Bella Vista Ave
     CA 94920


     Andrew Smith

     Email: ah_smith@acm.org
     Fax:  +1.415.345.1827

     Allyn Romanow
     Cisco Systems
     170 W Tasman Drive
     San Jose, CA 95134

     Phone +1.408.525.8836
     Email: allyn@cisco.com

Full Copyright Statement

     Copyright (C) The Internet Society (2002). All Rights Reserved.

     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain
     it or assist in its implementation may be prepared, copied,
     published and distributed, in whole or in part, without restriction
     of any kind, provided that the above copyright notice and this
     paragraph are included on all such copies and derivative works.
     However, this document itself may not be modified in any way, such
     as by removing the copyright notice or references to the Internet
     Society or other Internet organizations, except as needed for the
     purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards process
     must be followed, or as required to translate it into languages
     other than English.

     The limited permissions granted above are perpetual and will not be
     revoked by the Internet Society or its successors or assigns.

Finn and others           Expires December 2002                [Page 11]

Internet-Draft              Bridging and VPLS               21 June 2002

     This document and the information contained herein is provided on

Finn and others           Expires December 2002                [Page 12]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/