INTERNET DRAFT                                 Pranjal Kumar Dutta
L2VPN Working Group                            Lucent Technologies
Expires: January 2007                          July 2006



        LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS
                  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt



Status of this Memo

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

IPR Disclosure Acknowledgement

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

Abstract

   [VPLS-LDP] defines a mechanism to remove or unlearn MAC addresses
   that have been dynamically learned in a Virtual Switch Instance(VSI)
   for faster convergence on topology change. One of the ways to
   accomplish this is by sending LDP Address Withdraw Message with
   empty MAC List when topology change occurs due to spoke PW (Pseudo
   Wires) switchover at dual-homed capable Multi-Tenant Unit Switch
   (MTU-s) in a Hierarchical VPLS (H-VPLS) domain. On receiving this
   message a PE-rs removes all MAC addresses associated with the VSI
   except the ones learned in the session over which the message is
   received. The MAC addresses removed in this procedure also include
   the MAC addresses learned from LDP sessions in the same VSI that
   are not actually affected due to such topology change. This document
   proposes an extension to LDP Address Withdraw Message with empty MAC
   List defined in [VPLS-LDP], which enables the PE-rs receiving the
   message to remove only the MAC addresses that are affected and need
   to be relearned.


   Dutta.               Expires January 2007                  [Page 1]


   Internet Draft  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt


1. Conventions

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


2. Terminology

   This document uses terminology described in [RFC3036], [L2VPN-FRWK],
   and [VPLS-LDP].


3. Table of Contents

   1.  Conventions..................................................2
   2.  Terminology..................................................2
   3.  Table of Contents............................................2
   4.  Introduction.................................................2
       4.1 Flushing of MACs learned from unaffected PE-rs...........3
   5.  Mechanism to avoid flushing of MACs from unaffected PE-rs....4
       5.1 LDP Extension on LSR-ID..................................4
       5.2 Processing of LSR-ID.....................................5
       5.3 MAC Address Withdrawal Procedure with LSR ID.............6
       5.4 Applicability of LSR-ID..................................6
   6.  Security Considerations......................................6
   7.  Acknowledgements.............................................7
   8.  References...................................................7
   9.  Author's Address.............................................7


4. Introduction

   MAC Address Withdrawal is a mechanism proposed for faster
   convergence in [VPLS-LDP] to remove or unlearn MAC addresses within
   a VSI that have been dynamically learned. One example where MAC
   Address Withdrawal is required is as a result of topology change due
   to failure of primary spoke PW or primary PE-rs in a dual-homed
   H-VPLS scenerio. This is accomplished by sending a LDP Address
   Withdraw Message with list of MAC addresses to be removed to all
   other PE-rs (Provider Edge)devices over the corresponding LDP
   sessions. In order to minimize the impact on LDP convergence time
   when MAC List TLV contains a large number of MAC Addresses, it may
   be preferable to send a LDP Address Withdraw Message with an empty
   MAC address list. The rule for processing the LDP Address Withdraw
   Message with empty MAC List is defined in [VPLS-LDP] as follows:

   - Remove all the MAC addresses associated with the VPLS instance
     (specified by FEC TLV) except the MAC addresses learned over the
     PW associated with this signaling session over which the message
     was received.


   Dutta.               Expires January 2007                  [Page 2]


   Internet Draft  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt


   This document identifies one problem related to the current proposal
   of MAC Address Withdrawal Mechanism as defined in [VPLS-LDP] and
   a solution is proposed. Following is a dual-homed H-VPLS scenerio
   for single VSI where the problem in current MAC Address Withdrawal
   Mechanism with empty MAC List as per [VPLS-LDP] is explained.


                                 PE1-rs                     PE3-rs
                               +--------+                  +--------+
                               |        |                  |        |
                               |   --   |                  |   --   |
   Customer Site 1             |  /  \  |------------------|  /  \  |->
      CE-1              /------|  \ s/  |                  |  \S /  |
        \    primary spoke PW  |   --   |           /------|   --   |
         \            /        +--------+          /       +--------+
          \  MTU-s   /              |    \        /             |
          +--------+/               |     \      /              |
          |        |                |      \    /               |
          |   --   |                |       \  /                |
          |  /  \  |                |      H-VPLS Full Mesh Core|
          |  \S /  |                |       / \                 |
          |   --   |                |      /   \                |
         /+--------+\               |     /     \               |
        /     secondary spoke PW    |    /       \              |
       /              \        +--------+         \--------+--------+
      CE-2             \       |        |                  |        |
   Customer Site 2      \------|  --    |                  |  --    |
                               | /  \   |------------------| /  \   |->
                               | \s /   |                  | \S /   |
                               |  --    |                  |  --    |
                               +--------+                  +--------+
                                 PE2-rs                       PE4-rs

           Figure 1: Dual homed MTU-s in 2 tier hierarchy H-VPLS


4.1 Flushing of MACs learned from unaffected PE-rs

   In the scenerio in figure.1, in normal condition only the primary
   spoke PW is active at MTU-s and so PE1-rs is acting as the primary
   device for the dual homed MTU-s. The MAC addresses located at
   customer sites (beyond CE1 and CE2) are learned by PE1-rs over the
   primary spoke PW. PE2-rs, PE3-rs and PE4-rs may learn those MAC
   addresses in the H-VPLS core on the respective hub PWs over the
   signaling session with PE1-rs.

   When spoke PW switchover takes place at MTU-s to the secondary PW,
   PE2-rs becomes the primary PE-rs device and traffic in the VSI from
   CE1 and CE2 is diverted over the spoke PW to PE2-rs. MTU-s may
   desire to unlearn or remove all the MAC addresses that are learned
   across the VSI earlier through PE1-rs for faster convergence. MTU-s
   may send LDP Address Withdraw Message with empty MAC List to PE2-rs.
   As per the rules of processing for empty MAC list defined in
   [VPLS-LDP] PE2-rs should flush all the MAC addresses learned for the
   VSI over the signaling sessions with PE1-rs, PE3-rs and PE4-rs. But
   the actual MAC addresses that require flushing and relearning at


   Dutta.               Expires January 2007                  [Page 3]


   Internet Draft  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt


   PE2-rs are the MAC addresses that have been learned on PW from
   PE1-rs. MAC address flushing and relearning are resource intensive
   processes at PE-rs devices when there is a large number of MAC
   addresses associated in the VSI. After processing the LDP Address
   Withdraw Message with empty MAC List at PE2-rs, it is propagated to
   all other PE-rs devices in the VSI in full mesh core. Same
   processing rules are applied at all other PE-rs devices. For
   example, at PE3-rs all the MAC addresses learned from PWs connected
   to PE1-rs and PE4-rs will be flushed and relearned subsequently. As
   the number of PE-rs devices increases, the number of unaffected MAC
   addresses flushed also increases. With large number of VSIs
   provisioned in the H-VPLS domain the amount of unnecessary MAC
   address flushing and learning intensifies. An extension to the
   existing MAC Address Withdraw Mechanism with empty MAC List is
   proposed that enables a PE-rs device to flush only MAC addresses
   that need relearning due to topology change at MTU-s.


5. Mechanism to avoid flushing of MACs from unaffected PE-rs

   A mechanism is proposed that enables a PE-rs to remove or unlearn
   MAC addresses only from the PW over a signaling session that are
   required to be removed or unlearned due to topology change at dual-
   homed capable MTU-s in H-VPLS.

5.1 LDP Extension on LSR-ID

   A new optional LSR-ID TLV is defined which MAY be propagated within
   LDP Address Withdraw Message with empty MAC List to PE-rs device(s)
   in the VSI. The LSR-ID TLV carries the unique LSR identification
   info of a PE-rs device in the VSI. A new LSR-ID Element is defined
   to encode the LSR identification info of a PE-rs device. The LSR-ID
   TLV MUST contain a single LSR-ID Element.

   The encoding of LSR-ID TLV follows standard LDP TLV encoding defined
   in [RFC3036] and is as follows :

       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| Type (LSR-ID )            |      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   LSR-ID Element                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Both U bit and F bit in the TLV MUST be set to 1.
   Type number for LSR-ID will be allocated from IANA later.
   Length depends on the type of LSR-ID Element. There can be several
   types of LSR-ID Elements.


   Dutta.               Expires January 2007                  [Page 4]


   Internet Draft  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt


   The LSR-ID Element encoding is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type (LSR-ID Element Type)|          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   LSR Identifier   (Variable)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Type            Field of size 2 octets that contains the type
                          of LSR-ID Element.

        Length            Field of size 2 octets that contains the
                          length of the LSR Identifier in number of
                          octets.

        LSR Identifier    Variable length field that contains the
                          value of LSR Identifier based on specific
                          type.


   In this version one LSR-ID Element value encoding is defined and is
   as follows:

   LSR-ID Element   Type         Length    Value
   type name

   Generic          0x01            4          LSR Identifier = The first
                                             four octets of LDP
                                             Identifier[RFC3036] that
                                             identify a LSR and is
                                             globally unique value,
                                             such as a 32-bit router Id
                                             assigned to the LSR.

   Definitions and usage of other types of LSR-ID Elements is a subject
   for future study.

5.2 Processing of LSR-ID

   This section defines the processing rules of LSR-ID TLV with Generic
   LSR-ID Element (type 0x01). The LSR-ID TLV is applicable ONLY in LDP
   Address Withdraw Message with empty MAC List as defined in
   [VPLS-LDP] and MAY be sent as optional parameter. When a MTU-s
   triggers MAC Address Withdrawal after spoke PW failover to a PE-rs
   device, it MAY send the LSR-ID TLV option with LSR Identifier of
   that PE-rs device. There may be some applications that may require a
   PE-rs device to initiate MAC Address Withdrawal in a VSI. In such
   case the PE-rs device that initiates MAC Address Withdrawal MAY use
   its own LSR Identifier in the LSR-ID TLV option. Irrespective of
   whether it is the MTU-s or PE-rs device that initiates the MAC
   Address Withdrawal, a PE-rs devices receiving the option follows the
   same processing rules as defined in this section.

   When a PE-rs device receives a LDP Address Withdraw Message with
   empty MAC List and the LSR-ID TLV option, the PE-rs SHOULD flush all
   the MAC addresses learned from the PW over LDP signaling session


   Dutta.               Expires January 2007                  [Page 5]


   Internet Draft  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt


   with the PE-rs device identified by LSR-ID Element. Note that a
   PE-rs device uses the same local router Id in LDP sessions with all
   other PE-rs devices in the full mesh core.

   When a PE-rs device receives LDP Address Withdraw Message with empty
   MAC List and LSR-ID TLV option, and the PE-rs does not have LDP
   session with the one specified by the LSR Identifier then it SHOULD
   NOT flush or relearn any MAC address in the VSI.

   If a PE-rs device receives a LDP Address Withdraw Message with the
   LSR-ID option included when there is a valid MAC address list then
   it SHOULD ignore the option and deal with MAC addresses explicitly
   as per corresponding procedures defined in [VPLS-LDP].

   When a PE-rs that doesn't support LSR-ID TLV receives LDP Address
   Withdraw Message with this option then it SHOULD ignore the option
   and SHOULD follow the processing rules as per [VPLS-LDP].


5.3 MAC Address Withdrawal Procedure with LSR-ID

   This section explains the MAC Address Withdrawal Procedure in the
   scenerio in figure.1 when LSR-ID TLV option is used with Generic
   LSR-ID Element. In the scenerio, PE1-rs is the primary device for
   the dual homed MTU-s in normal condition. The traffic received for
   the VSI from CE1 and CE2 is forwarded by MTU-s to PE1-rs and the
   corresponding MAC addresses are learned by PE1-rs over the primary
   spoke PW. Accordingly other PE-rs devices in the VSI in full mesh
   core may learn those MAC addresses on their respective PWs over the
   LDP signaling session with PE1-rs. After a PW switchover takes place
   at MTU-s to secondary spoke PW, PE2-rs is selected as primary device
   and MTU-s diverts the traffic from CE1 and CE2 to PE2-rs. MTU-s may
   send a MAC Address Withdraw Message for the VSI with empty MAC List
   and the optional LSR-ID TLV. The corresponding Generic LSR-ID
   Element within the option may contain the LSR Identifier from the
   LDP session with PE1-rs that uniquely identifies PE1-rs in the
   H-VPLS domain. When the message is received at PE2-rs the processing
   engine SHOULD remove all MAC addresses learned on the PW over the
   LDP session with the device identified by LSR-ID TLV, that is
   PE1-rs. PE2-rs propagates the LDP Address Withdraw Message to all
   other PE-rs devices connected in full mesh for the VSI. Same
   processing rules SHOULD be applied at all other PE-rs devices. For
   example, when the message is received at PE3-rs it identifies the
   LSR-ID to be associated with the signaling session with PE1-rs, So
   PE3-rs SHOULD remove all MAC addresses learned on the PW over the
   signaling session with PE1-rs.

5.4 Applicability of LSR-ID

   The use of the LSR-ID TLV is applicable with 2-tier HVPLS domains as
   defined in [VPLS-LDP]. The use of the LSR-ID TLV in inter-domain
   connectivity models or 3-tier hierarchy models is out of scope.

6. Security Considerations

   Security aspects of this draft will be discussed at a later point.


   Dutta.               Expires January 2007                 [Page 6]


   Internet Draft  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt


7. Acknowledgments

   The author wish to thank Marc Lasserre, John Rigby, Prashanth Ishwar
   and Vipin Jain for valuable suggestions, both technical and
   editorial, for correcting and improving the document.

8. References

   [L2VPN-FRWK]     Andersson, L., et al. "Framework for Layer 2
                    Virtual Private Networks (L2VPNs)", work in
                    progress.

   [VPLS-LDP]       Lasserre, M., et al. "Virtual Private LAN Services
                    using LDP",work in progress.

   [RFC3036]        Andersson, L., et al. "LDP Specification",RFC 3036,
                    January 2001.

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


 9. Author's Address

   Pranjal Kumar Dutta
   Lucent Technologies India Pvt. Ltd
   #3/1 Millers Road, J P Techno Parks
   Bangalore - 560052
   India

   Phone: +91.80.5113.1932
   Fax  : +91.80.5113.1936
   Email: pdutta@lucent.com


IPR Disclosure Acknowledgement

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed
  to pertain to the implementation or use of the technology described
  in this document or the extent to which any license under such
  rights might or might not be available; nor does it represent that
  it has made any independent effort to identify any such rights.
  Information on the procedures with respect to rights in RFC
  documents can be found in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use
  of such proprietary rights by implementers or users of this
  specification can be obtained from the IETF on-line IPR repository
  at http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at ietf-
  ipr@ietf.org.


   Dutta.               Expires January 2007                  [Page 7]


   Internet Draft  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt


Copyright Notice

  Copyright (C) The Internet Society (2006).  This document is
  subject to the rights, licenses and restrictions contained in BCP
  78, and except as set forth therein, the authors retain all their
  rights.

Disclaimer

  This document and the information contained herein are provided on
  an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
  REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
  THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
  THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
  ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
  PARTICULAR PURPOSE.

































   Dutta.               Expires January 2007                  [Page 8]

   Internet Draft  draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt