Skip to main content

Node redundancy provisioning for VPLS Inter-domain
draft-liu-l2vpn-vpls-inter-domain-redundancy-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Ran Chen , Zhihua Liu
Last updated 2011-09-28 (Latest revision 2011-07-01)
Replaced by draft-ietf-l2vpn-vpls-inter-domain-redundancy, draft-ietf-l2vpn-vpls-inter-domain-redundancy, RFC 7309
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-l2vpn-vpls-inter-domain-redundancy-01
Networking Working Group                                          Z. Liu
Internet-Draft                                             China Telecom
Intended status: Informational                                    L. Jin
Expires: March 31, 2012                                          R. Chen
                                                                     ZTE
                                                      September 28, 2011

           Node redundancy provisioning for VPLS Inter-domain
            draft-liu-l2vpn-vpls-inter-domain-redundancy-01

Abstract

   In many VPLS deployment based on [RFC4762], inter-domain has been
   deployed without node redundancy, or only with node redundancy in one
   domain.  This document describes how to deploy inter-domain VPLS
   based on [RFC4762] with node redundancy in both domain.  The draft
   reuses the existing protocols without introducing any new protocols.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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 progress."

   This Internet-Draft will expire on March 31, 2012.

Copyright Notice

   Copyright (c) 2011 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

Liu, et al.              Expires March 31, 2012                 [Page 1]
Internet-Draft    Node redundancy for VPLS Inter-domain   September 2011

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Redundancy scenario with ICCP . . . . . . . . . . . . . . . . . 3
   5.  Node redundancy for VPLS Inter-domain . . . . . . . . . . . . . 4
   6.  MAC Withdraw procedure  . . . . . . . . . . . . . . . . . . . . 5
   7.  Load Balancing  . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  Normative references  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Liu, et al.              Expires March 31, 2012                 [Page 2]
Internet-Draft    Node redundancy for VPLS Inter-domain   September 2011

1.  Introduction

   In many VPLS deployment based on [RFC 4762], inter-domain has been
   deployed without node redundancy, or only with node redundancy in one
   domain.  This document describes how to deploy inter-domain VPLS
   based on [RFC 4762] with node redundancy in both domain.  The draft
   reuses the existing protocols without introducing any new protocols.
   The domain in this document refers to AS, or other administrative
   domain.

2.  Conventions used in this document

   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.  Motivation

   Inter-AS VPLS has now been wildly deployed between two providers.
   Usually, the physical link and ASBR between the two providers would
   carry many kinds of service, then it is important to provider link
   and node redundancy for such kind of inter-AS service to ensure high
   availability.

   Some current high availability deployments of inter-AS VPLS are
   provided by MC-LAG (Multi-Chassis Link Aggregation) and
   [I-D.ietf-pwe3-iccp], but there is a pre-condition that the
   interconnected link between the two providers are Ethernet link.
   There are also many interconnection cases between two providers to
   use POS (Packet over Sonet/SDH) link on which MC-LAG cannot be
   enabled.  Moreover, it is also required for the VPLS between two
   providers to ensure bandwidth control, QoS, MAC address control and
   Broadcast/Multicast traffic control.  Then from the technical point
   of view, it is necessary to use PW to interconnect the two VPLS in
   its corresponding providers, and also to provide link/node redundancy
   to ensure high availability.

4.  Redundancy scenario with ICCP

   The following figure presents a typical inter-AS VPLS deployment
   topology.  PE3 and PE4 are the VPLS edge nodes in network of operator
   A, and PE5 and PE6 are the VPLS edge nodes in network of operator B.
   The PE3/PE4/PE5/PE6 may be ASBR of the AS, or VPLS PE within its own
   AS.

Liu, et al.              Expires March 31, 2012                 [Page 3]
Internet-Draft    Node redundancy for VPLS Inter-domain   September 2011

                +---------+                       +---------+
        +---+   | +-----+ |     active PW1        |  +-----+|    +---+
        |PE1|---|-| PE3 |-|-----------------------|--| PE5 ||----|PE7|
        +---+\  |/+-----+ |                       |  +-----+\   /+---+
         |    \ /  | *    |                       |    * |  |\ /   |
         |     \|  | |ICCP|                       |ICCP| |  | \    |
         |    / \  | *    |                       |    * |  |/ \   |
        +---+/  |\+-----+ |                       |  +-----+/   \+---+
        |PE2|---|-| PE4 |-|-----------------------|--| PE6 ||----|PE8|
        +---+   | +-----+ |     standby PW2       |  +-----+|    +---+
                |         |                       |         |
                |         |                       |         |
                |  RG1    |                       |  RG2    |
                +---------+                       +---------+
                operator A network                operator B network

                                 Figure 1

   When inter-AS VPLS is deployed with node redundancy on both AS side,
   node redundancy protocol ICCP[I-D.ietf-pwe3-iccp]SHOULD be
   implemented on the VPLS edge nodes of the AS, e.g, ICCP should be
   running between PE3 and PE4, PE5 and PE6.

   There are several deployment scenarios for inter-domain VPLS:
   o  ICCP deployment option: ICCP is deployed on VPLS edge nodes in one
      domain, or in both domain;
   o  PW redundancy mode: independent or master/slave;

   From the operator's point of view, it is important to keep the
   technical balance and technical independence between the two
   operators.  One operator will not highly rely on the other operator's
   technical choice for inter-domain VPLS node redundancy.  Then it is
   highly recommended to be the deployment scenario as follows:
   o  ICCP deployment option: ICCP is deployed on VPLS edge nodes in
      both domain;
   o  PW redundancy mode: independent only;

   And this draft will only focus on the above deployment option, other
   options are out of the scope.

5.   Node redundancy for VPLS Inter-domain

   The PEs in the RG are required to run an inter-chassis communication
   protocol ([I-D.ietf-pwe3-iccp]) in order to select which
   pseudowire(s) should be in active/standby state for a given VPLS
   service instance.

Liu, et al.              Expires March 31, 2012                 [Page 4]
Internet-Draft    Node redundancy for VPLS Inter-domain   September 2011

   The procedures to select active/standby pseudowire(s):
   o  The PEs in the RG enable ICCP[I-D.ietf-pwe3-iccp].
   o  The PEs should establish a PW-RED application connection using the
      mechanism described in [I-D.ietf-pwe3-iccp], section 9.1.1.
   o  When the PW-RED application connection first comes up, Each PE
      MUST advertise it local PW configuration to other PEs that are
      members of the same RG.  As part of the configuration information,
      the PE should advertise a PW priority value that is used to
      determine the precedence of a given pseudowire.
   o  Pseudowire Status Synchronization.  A PE MAY re-advertise its PW-
      RED state in an unsolicited/solicited manner, the detailed
      mechanism is described in [I-D.ietf-pwe3-iccp], section 9.1.3.

   The PEs SHOULD then use PW redundancy bit
   [I-D.ietf-pwe3-redundancy-bit] or basic PW status bit [RFC4447] to
   advertise the outcome of the arbitration to the peer PE(s).

   Before deploying inter-domain VPLS, the operator MUST negotiate to
   configure same PW priority at two end-points.  If different PW
   priority value is configured at the two PW end-points, e.g, PE3 and
   PE5 for PW1, and PE4 and PE6 for PW2 in figure 1, it is possible to
   select PE3 and PE6 as active for the two domain, then both PW1 and
   PW2 will be standby according to the independent mode in
   [I-D.ietf-pwe3-redundancy-bit].

6.   MAC Withdraw procedure

   It MAY be desirable to remove or unlearn MAC addresses that have been
   dynamically learned for faster convergence.  This is accomplished by
   sending an LDP Address Withdraw Message.  PE SHOULD not advertise MAC
   Address Withdraw message from one domain to the other.
   Correspondingly, VPLS PE that connects another domain SHOULD also
   reject any MAC Address Withdraw message received from that domain.

   The following will describe MAC Address Withdraw of VPLS Inter-AS in
   detail.  When PE3 node failure and detecting that a remote PE3 that
   is member of the same RG, has got down, PE4 will send Address
   Withdraw Message with empty MAC list or positive MAC flush message
   [I-D.ietf-l2vpn-vpls-ldp-mac-opt] to other PEs that in the same
   AS(e.g.,PE2,PE3,and PE1), but will not send to PE6.  The receiver PEs
   nodes flush the MAC addresses associated with corresponding VPLS
   instance.  Upon detecting remote-end PE3 failure, PE5 will send
   negative MAC flush message [I-D.ietf-l2vpn-vpls-ldp-mac-opt] to other
   PEs that in the same AS(e.g., PE6, PE7, and PE8).  The receiver PEs
   flush the MAC addresses associated with corresponding VPLS instance.
   When PW between PE3 and PE5 failure, PE3 and PE5 will only send
   negative MAC flush message to other PEs in its own AS.

Liu, et al.              Expires March 31, 2012                 [Page 5]
Internet-Draft    Node redundancy for VPLS Inter-domain   September 2011

7.  Load Balancing

   It is recommended to configure different PW priority values for
   different VPLS instance, then the active PW of different VPLS will be
   running on different PEs, to provide load balancing between the two
   PE in one domain.

                 +------------+             +------------+
   +--------+    | +--------+ |             | +--------+ |    +--------+
   |        |    | |  PE3   | |             | |  PE5   | |    |        |
   |        |    | |+------+| | active PW1  | |+------+| |    |        |
   |        |    | ||VPLS_A||-|-------------| ||VPLS_A|| |    |        |
   |  PE1   |    | |+------+| |             | |+------+| |    |   PE7  |
   |        |    | |+------+| | standby PW3 | |+------+| |    |        |
   |        |    | ||VPLS_B||-|-------------| ||VPLS_B|| |    |        |
   |        |----|-|+------+| |             | |+------+| |    |        |
   +--------+\   |/+--------+ |             | +--------+\|   /+--------+
      |       \  /    | *     |             |     * |    \  /     |
      |        \/|    | |ICCP |             | ICCP| |    |\/      |
      |        /\|    | |     |             |     | |    |/\      |
      |       /  \    | *     |             |     * |    /  \     |
   +--------+/   |\+--------+ |             | +--------+/|   \+--------+
   |        |----|-|  PE4   | |             | |  PE6   |-|----|        |
   |        |    | |+------+| | standby PW2 | |+------+| |    |        |
   |        |    | ||VPLS_A||-|-------------| ||VPLS_A|| |    |        |
   |  PE2   |    | |+------+| |             | |+------+| |    |   PE8  |
   |        |    | |+------+| | active  PW4 | |+------+| |    |        |
   |        |    | ||vPLS_B||-|-------------| ||VPLS_B|| |    |        |
   |        |    | |+------+| |             | |+------+| |    |        |
   +--------+    | +--------+ |             | +--------+ |    +--------+
                 +------------+             +------------+
                operator A network          operator B network

                                 Figure 2

   In figure 2, it shows two VPLS inter-AS deployment.  VPLS_A will have
   the PW between PE3 and PE5 with higher priority than the one between
   PE4 and PE6, while VPLS_B will have the PW between PE4 and PE6 with
   higher priority than the one between PE3 and PE5.  Then PE3&PE4 or
   PE5&PE6 can provider load balance among different VPLS instance.

8.  Security Considerations

   This section will be added in a future version.

Liu, et al.              Expires March 31, 2012                 [Page 6]
Internet-Draft    Node redundancy for VPLS Inter-domain   September 2011

9.  Normative references

   [I-D.ietf-l2vpn-vpls-ldp-mac-opt]
              Dutta, P., Balus, F., Stokes, O., and G. Calvignac, "LDP
              Extensions for Optimized MAC Address Withdrawal in
              H-VPLS", draft-ietf-l2vpn-vpls-ldp-mac-opt-04 (work in
              progress), June 2011.

   [I-D.ietf-pwe3-iccp]
              Martini, L., Salam, S., Sajassi, A., Bocci, M.,
              Matsushima, S., and T. Nadeau, "Inter-Chassis
              Communication Protocol for L2VPN PE Redundancy",
              draft-ietf-pwe3-iccp-05 (work in progress), April 2011.

   [I-D.ietf-pwe3-redundancy]
              Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
              Redundancy", draft-ietf-pwe3-redundancy-05 (work in
              progress), September 2011.

   [I-D.ietf-pwe3-redundancy-bit]
              Muley, P. and M. Aissaoui, "Pseudowire Preferential
              Forwarding Status Bit", draft-ietf-pwe3-redundancy-bit-05
              (work in progress), September 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
              (VPLS) Using Label Distribution Protocol (LDP) Signaling",
              RFC 4762, January 2007.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

Liu, et al.              Expires March 31, 2012                 [Page 7]
Internet-Draft    Node redundancy for VPLS Inter-domain   September 2011

Authors' Addresses

   Zhihua Liu
   China Telecom
   109 Zhongshan Ave.
   Guangzhou 510630
   P.R.China

   Email: zhliu@gsta.com

   Lizhong Jin
   ZTE Corporation
   889 Bibo Road
   Shanghai 201203
   P.R.China

   Email: lizhong.jin@zte.com.cn

   Ran Chen
   ZTE Corporation
   68 Zijinghua Road
   Nanjing 210012
   P.R.China

   Email: chen.ran@zte.com.cn

Liu, et al.              Expires March 31, 2012                 [Page 8]