Internet DRAFT - draft-liu-l2vpn-vpls-inter-domain-redundancy

draft-liu-l2vpn-vpls-inter-domain-redundancy






Networking Working Group                                          Z. Liu
Internet-Draft                                             China Telecom
Intended status: BCP                                              L. Jin
Expires: January 3, 2013                                         R. Chen
                                                                     ZTE
                                                                  D. Cai
                                                                S. Salam
                                                                   Cisco
                                                            July 2, 2012


             Redundancy provisioning for VPLS Inter-domain
            draft-liu-l2vpn-vpls-inter-domain-redundancy-04

Abstract

   In many VPLS deployments based on RFC4762, inter-domain connectivity
   has been deployed without node redundancy, or with node redundancy in
   a single domain.  This document describes a solution for inter-domain
   VPLS based on RFC4762 with node and link redundancy in both domains.

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 January 3, 2013.

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



Liu, et al.              Expires January 3, 2013                [Page 1]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


   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.  Conventions used in this document . . . . . . . . . . . . . . . 3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Network Use Case  . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  PW redundancy application procedure for inter-domain  . . . . . 5
     5.1.  ICCP switchover condition . . . . . . . . . . . . . . . . . 6
       5.1.1.  Inter-domain PW failure . . . . . . . . . . . . . . . . 6
       5.1.2.  PE node isolation . . . . . . . . . . . . . . . . . . . 6
       5.1.3.  PE node failure . . . . . . . . . . . . . . . . . . . . 6
     5.2.  Inter-domain redundancy with two-PWs  . . . . . . . . . . . 6
     5.3.  Inter-domain redundancy with four-PWs . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative references  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

























Liu, et al.              Expires January 3, 2013                [Page 2]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


1.  Introduction

   In many VPLS deployment based on [RFC4762], inter-domain connectivity
   has been deployed without node redundancy, or with node redundancy in
   a single domain.  This document describes a solution for inter-domain
   VPLS based on [RFC4762] with node and link redundancy in both domain.
   The domain in this document refers to AS, or other administrative
   domains.


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 offerings are widely deployed in service provider
   networks today.  Typically, the ASBRs and associated physical links
   that connect the domains carry a multitude of services.  As such, it
   is important to provide link and node redundancy, to ensure service
   high availability and meet end customer service level agreements
   (SLAs).

   Several current deployments of inter-AS VPLS are implemented using
   Inter-AS Option A, where VLANs are used to hand-off the services
   between the two domains.  In these deployments, link/node redundancy
   is achieved using MC-LAG (Multi-Chassis Link Aggregation) and
   [I-D.ietf-pwe3-iccp].  This, however, places two restrictions on the
   interconnect: the two domains must be interconnected using Ethernet
   links, and the links must be homogeneous, i.e. of the same speed, in
   order to be aggregate-able.  These two conditions cannot always be
   guaranteed in live deployments.  For instance, there are many
   scenarios where the interconnect between the domains uses POS (Packet
   over Sonet/SDH), thereby ruling out the applicability of MC-LAG as a
   redundancy mechanism.  As such, from a technical point of view, it is
   desirable to use PWs to interconnect the VPLS domains, and to offer
   resiliency using PW redundancy mechanisms.

   MP-BGP can be used for VPLS inter-domain protection, as described in
   [RFC6074], using either Option B or Option C inter-AS models.
   However, with this solution, the protection time relies on BGP
   control plane convergence.  In certain deployments, with tight SLA
   requirements on availability, this mechanism may not provide the
   desired failover time characteristics.  Furthermore, in certain
   situations MP-BGP is not deployed for VPLS.  The redundancy solution



Liu, et al.              Expires January 3, 2013                [Page 3]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


   described in this draft reuses ICCP [I-D.ietf-pwe3-iccp] and PW
   redundancy [I-D.ietf-pwe3-redundancy] to provide fast convergence.

   Furthermore, in the case where Label Switched Multicast is not used
   for VPLS multicast [I-D.ietf-l2vpn-vpls-mcast], the solution
   described here provides a better behavior compared to inter-AS option
   B: with option B, each PE must perform ingress replication to all
   other PEs in its local as well as the remote domain.  Whereas, with
   the ICCP solution, the PE only replicates to local PEs and to the
   ASBR.  The ASBR then sends traffic P2P to the remote ASBR, and the
   remote ASBR replicates to its local PEs.  As a result, the load of
   replication is distributed and is more efficient than option B.

   The two PW redundancy modes defined in
   [I-D.ietf-pwe3-redundancy-bit], namely independent mode and master/
   slave mode, are applicable in this solution.  In order to maintain
   control plane separation between the two domains, the independent
   mode is preferred by operators.  While the master/slave mode provides
   some enhanced capabilities and, hence, is included in this draft.


4.  Network Use Case

   There are two network use cases for VPLS inter-domain redundancy:
   two-PWs redundancy case, and four-PWs redundancy case.

   Figure 1 presents an example use case with two inter-domain PWs.
   PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs
   within its own AS.  A deployment example of this use case is where
   there are only two physical links between the two domains and PE3 is
   physically connected with PE5, and PE4 is physically connected with
   PE6.


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



Liu, et al.              Expires January 3, 2013                [Page 4]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


               operator A network                operator B network


                                 Figure 1

   Figure 2 presents a four-PWs inter-domain VPLS redundancy use-case.
   PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs
   within its own AS.  A deployment example of this use case is where
   there are four physical links between the two domains and the four
   PEs are physically connected with each other with four links.


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


                                 Figure 2


5.  PW redundancy application procedure for inter-domain

   PW redundancy application procedures are described in section 9.1 of
   [I-D.ietf-pwe3-iccp].  When a PE node encounters a failure, the other
   PE takes over.  This document reuses the PW redundancy mechanism
   defined in [I-D.ietf-pwe3-iccp], with new ICCP switchover conditions
   as specified in the following section.

   There are two PW redundancy modes defined in
   [I-D.ietf-pwe3-redundancy-bit]: Independent mode and Master/Slave
   mode.  For the inter-domain four-PW scenario, it is required for the
   PEs to ensure that the same mode is supported on the two ICCP peers
   in the same RG.






Liu, et al.              Expires January 3, 2013                [Page 5]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


5.1.  ICCP switchover condition

5.1.1.  Inter-domain PW failure

   When a PE receives advertisements from the active PE, in the same RG,
   indicating that all the inter-domain PW status has changed to DOWN/
   STANDBY, then if it has the highest priority (after the advertising
   PE), it SHOULD advertise active state for all of its associated
   inter-domain PWs.

5.1.2.  PE node isolation

   When a PE detects failure of all PWs to the local domain, it SHOULD
   advertise standby state for all its inter-domain PWs to trigger
   remote PEs to switchover.

5.1.3.  PE node failure

   When a PE node detects that the active PE, that is member of the same
   RG, has gone down, if the local PE has redundant PWs for the affected
   services and has the highest priority (after the failed PE), it
   advertises the active state for all associated inter-domain PWs.

5.2.  Inter-domain redundancy with two-PWs

   In this use case, it is recommended that the operation be as follows:
   o  ICCP deployment option: ICCP is deployed on VPLS edge nodes in
      both domain;
   o  PW redundancy mode: independent mode only;
   o  Protection architectures: 1:1 (1 standby, 1 active).

   The switchover rules described in section 5.2 apply.  Before
   deploying this inter-domain VPLS, the operators MUST negotiate to
   configure same PW high/low priority at the two PW end-points.  E.g,
   in figure 1, PE3 and PE5 MUST both have higher/lower priority than
   PE4 and PE6, otherwise both PW1 and PW2 will be in standby state.

5.3.  Inter-domain redundancy with four-PWs

   In this use case, there are generally three options to provide 1:1
   protection or 3:1 protection.  The inter-domain PWs that connect to
   the same PE should have proper PW priority to advertise same active/
   standby state.  E.g, in figure 2, both PW1 and PW3 connected to PE3
   would advertise active/standby state.

   For 1:1 protection model, the operation would be as follows:





Liu, et al.              Expires January 3, 2013                [Page 6]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


   o  ICCP deployment option: ICCP is deployed on VPLS edge nodes in
      both domains;
   o  PW redundancy mode: independent mode only;
   o  Protection architectures: 1:1(1 standby, 1 active).

   The switchover rules described in section 5.2 apply.  In this case,
   the operator does not need to do any coordination of the inter-domain
   PW priority.  The PE detecting one PW DOWN should set the other PW to
   STANDBY if available, and then synchronize the updated state to its
   ICCP peer.  When a PE detects that the PWs from ICCP peer PE are DOWN
   or STANDBY, it should switchover as described in section 5.2.1.

   There are two variants of the 3:1 protection model.  We will refer to
   them as option A and B. For option A of the 3:1 protection model, the
   support of 'request switchover' bit is required.  The operation is as
   follows:
   o  ICCP deployment option: ICCP is deployed on VPLS edge nodes in
      both domain;
   o  PW redundancy mode: Independent mode with 'request switchover' bit
      support;
   o  Protection architectures: 3:1 (3 standby, 1 active).

   In this case, the procedure on the PE for the PW failure is per
   section 6.3 of [I-D.ietf-pwe3-redundancy-bit], and with the following
   additions:
   o  When the PE detects failure of the active inter-domain PW, it
      should switch to the other local standby inter-domain PW if
      available, and send an updated LDP pseudowire status message with
      the 'request switchover' bit set on that local standby inter-
      domain PW to remote the PE;
   o  Local and remote PE should also update the new PW status to their
      ICCP peers, respectively, in Application Data Messages with PW-RED
      Synchronization Request TLV for corresponding service, so as to
      synchronize the latest PW status on both PE sides.
   o  While waiting for the acknowledgment, the PE that sent the
      'request switchover' bit may receive a switchover request from its
      ICCP peer's PW remote endpoint by virtue of the ICCP
      synchronization.  The PE MUST compare IP addresses with that PW
      remote peer.  The PE with a higher IP address will ignore the
      request and continue to wait for the acknowledgement from its peer
      in the remote domain.  The PE with the lower IP address MUST clear
      'request switchover' bit and set 'Preferential Forwarding' local
      status bit, and update the PW status to ICCP peer.
   o  The remote PE receiving 'request switchover' bit will acknowledge
      the request and activate the PW only when it is ready to take over
      as described in section 5.2, otherwise, it MUST ignore the
      request.




Liu, et al.              Expires January 3, 2013                [Page 7]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


   The node isolation failure and node failure is described in section
   5.2.

   For option B of 3:1 protection model, master/slave mode support is
   required, and should be as follows:
   o  ICCP deployment option: ICCP is deployed on VPLS edge nodes in
      only one domain;
   o  PW redundancy mode: master/slave only;
   o  Protection architectures: 3:1 (3 standby, 1 active).

   When master/slave PW redundancy mode is employed, the network
   operators of the two domains must agree on which domain PEs will be
   master, and configure the devices accordingly.  The inter-domain PWs
   that connect to one PE should have higher PW priority than the PWs on
   the other PE in the same RG.  The procedure on the PE for PW failure
   is as follows:
   o  The PE with higher PW priority should only enable one PW active,
      and the other PWs standby.
   o  When the PE detects active PW DOWN, it should enable the other
      local standby PW to be active with preference.  Only when the two
      inter-domain PWs connect to the PE are DOWN, the ICCP peer PE in
      the same RG would switchover as described in section 5.2..

   The node isolation failure and node failure is described in section
   5.2.


6.  Security Considerations

   This draft will have the same security properties of
   [I-D.ietf-pwe3-iccp] and [RFC4762].


7.  IANA Consideration

   No IANA allocation is required in this draft.


8.  Acknowledgements

   The authors wish to acknowledge the contributions of Daniel Cohn and
   Yubao Wang.

   Daniel Cohn
   Orckit-Corrigent 
   Email: danielc@orckit.com

   Yubao Wang
   ZTE Corporation 


Liu, et al.              Expires January 3, 2013                [Page 8]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


   Email: wang.yubao@zte.com.cn


9.  References

9.1.  Normative references

   [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-bit]
              Muley, P. and M. Aissaoui, "Pseudowire Preferential
              Forwarding Status Bit", draft-ietf-pwe3-redundancy-bit-07
              (work in progress), May 2012.

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

9.2.  Informative References

   [I-D.ietf-l2vpn-vpls-mcast]
              Aggarwal, R., Rekhter, Y., Kamite, Y., and L. Fang,
              "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-10 (work
              in progress), February 2012.

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

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

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and Luo, W., 
              "Provisioning, Auto-Discovery, and Signaling in Layer 2 
			  Virtual Private Networks (L2VPNs)", RFC 6074, January 
			  2011.







Liu, et al.              Expires January 3, 2013                [Page 9]

Internet-Draft      Redundancy for VPLS Inter-domain           July 2012


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


   Dennis Cai
   Cisco
   3750 Cisco Way,
   San Jose, California 95134
   USA

   Email: dcai@cisco.com


   Samer Salam
   Cisco
   595 Burrard Street, Suite 2123
   Vancouver, BC V7X 1J1
   Canada

   Email: ssalam@cisco.com






Liu, et al.              Expires January 3, 2013               [Page 10]