Skip to main content

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

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 Zhihua Liu , Lizhong Jin , Ran Chen
Last updated 2012-03-09
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-02
Networking Working Group                                          Z. Liu
Internet-Draft                                             China Telecom
Intended status: Informational                                    L. Jin
Expires: September 10, 2012                                      R. Chen
                                                         ZTE Corporation
                                                           March 9, 2012

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

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 September 10, 2012.

Copyright Notice

   Copyright (c) 2012 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 September 10, 2012               [Page 1]
Internet-Draft    Node redundancy for VPLS Inter-domain       March 2012

   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 in VPLS Inter-domain . . . . . . . . . . 5
     6.1.  MAC withdraw notification TLV format  . . . . . . . . . . . 6
     6.2.  Optimized MAC Withdraw processing . . . . . . . . . . . . . 7
   7.  Load Balancing  . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . . . 7
   10. Normative references  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

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

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 September 10, 2012               [Page 3]
Internet-Draft    Node redundancy for VPLS Inter-domain       March 2012

                +---------+                       +---------+
        +---+   | +-----+ |     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 September 10, 2012               [Page 4]
Internet-Draft    Node redundancy for VPLS Inter-domain       March 2012

   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.  In order to synchronize
      pseudowire state, "PW-RED State TLV" is send whenever the
      pseudowire state changes on a PE.  The 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 in VPLS Inter-domain

   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.

   In figure 1, when the active PW failure is detected by the PE3, it
   will trigger MAC Address Withdraw message into the full mesh.  By
   default, as per the processing rules defined in [RFC4762], upon PE4
   activates the standby PW, it will also send a MAC Address Withdraw
   message.  There would be two copies of MAC Address Withdraw message
   received by each PE, which would make the network convergence worse.

   What's more, there are two MAC withdraw capabilities defined,
   positive MAC withdraw (Flush-all-but-mine, defined in [RFC4762] and
   [I-D.ietf-l2vpn-vpls-ldp-mac-opt]), and negative MAC withdraw (Flush-

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

   all-from-me,defined in [I-D.ietf-l2vpn-vpls-ldp-mac-opt]).  If the
   two PE support only positive MAC withdraw, then PE4 is required to
   send MAC withdraw message when PW switching.  While if two PE support
   both positive & negative MAC withdraw or support only negative MAC
   withdraw capability, then PE3 is required to send MAC withdraw
   message when PE switching.

   In order to determine which PE to send MAC withdraw message is most
   appropriate, we introduce an MAC withdraw notification TLV in ICCP
   PW-RED application to negotiate the MAC withdraw capability.

6.1.   MAC withdraw notification TLV format

   The MAC withdraw notification TLV is describe as below:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |U|F| MAC withdraw notification |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |P|N| Reserved  |
       +-+-+-+-+-+-+-+-+

                                 Figure 2

   U-bit: Unknown bit.  This bit SHOULD be set to 1 (ignore if not
   understood)

   F-bit: Forward bit.  This bit SHOULD be set to 0 (do not forward if
   not understood)

   MAC withdraw notification TLV: It is requested in the IANA
   allocation.

   P-bit: Used to indicate whether the node supports the positive (N=0,
   Flush-all-but-mine) MAC withdraw capability.  P=1 indicates that the
   node has the capability to send the positive MAC withdraw message.

   N-bit: Used to indicate whether the node supports the negative (N=1,
   Flush-all-from-me) MAC withdraw capability.  N=1 indicates that the
   node has the capability to send the negative MAC withdraw message.

   Reserved: Reserved for future use.

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

   MAC withdraw notification TLV is advertised to a LDP ICCP peer if
   there is at least one RG enabled on the local PE, and this TLV should
   be carried in "RG Application Data" message.

6.2.  Optimized MAC Withdraw processing

   After receiving the MAC withdraw capability through MAC withdraw
   notification TLV, the PE should process as below:
   o  If the former active PE & standby PE support only the positive MAC
      withdraw capability, then former standby PE will trigger MAC
      withdraw with positive MAC withdraw message
      [I-D.ietf-l2vpn-vpls-ldp-mac-opt] to other PEs that in the same AS
      when active PW failures.
   o  If the former active PE & standby PE support only negative MAC
      withdraw capability or support both positive & negative MAC
      withdraw, then former active PE sends MAC Address withdraw message
      with negative MAC withdraw message
      [I-D.ietf-l2vpn-vpls-ldp-mac-opt] to other PEs that in the same AS
      when active PW failures.
   o  The former standby PE may send MAC Address withdraw message with
      positive MAC withdraw message [I-D.ietf-l2vpn-vpls-ldp-mac-opt] to
      other PEs that in the same AS when the active PE failures.

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.

8.  Security Considerations

   This section will be added in a future version.

9.  IANA Consideration

   This document creates a new "ICC RG parameter type" (MAC withdraw
   notification TLV) that is allocated by IANA, and a value of 0x0020 is
   suggested for assignment with this TLV.

10.  Normative references

   [I-D.ietf-l2vpn-vpls-ldp-mac-opt]
              Dutta, P., Balus, F., Stokes, O., and G. Calvignac, "LDP

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

              Extensions for Optimized MAC Address Withdrawal in
              H-VPLS", draft-ietf-l2vpn-vpls-ldp-mac-opt-05 (work in
              progress), October 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-06 (work in
              progress), February 2012.

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

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

Authors' Addresses

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

   Email: zhliu@gsta.com

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

   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 September 10, 2012               [Page 9]