One document matched: draft-kothari-l2vpn-vpls-flush-00.txt
Network Working Group B. Kothari
Internet-Draft R. Fernando
Updates: 4761 (if approved) Juniper Networks
Intended status: Standards Track October 27, 2008
Expires: April 30, 2009
VPLS Flush in BGP-based Virtual Private LAN Service
draft-kothari-l2vpn-vpls-flush-00.txt
Status of this Memo
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.
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.
This Internet-Draft will expire on April 30, 2009.
Kothari & Fernando Expires April 30, 2009 [Page 1]
Internet-Draft BGP VPLS Flush October 2008
Abstract
This document defines procedures that allow BGP based Virtual Private
LAN Service (VPLS) provider edge (PE) devices to send explicit flush
notifications to remote VPLS PEs.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Terminology . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. VPLS Flush Capability . . . . . . . . . . . . . . . . . . . . 5
3. VPLS-FLUSH Message . . . . . . . . . . . . . . . . . . . . . . 6
3.1. MAC List TLV . . . . . . . . . . . . . . . . . . . . . . . 8
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Kothari & Fernando Expires April 30, 2009 [Page 2]
Internet-Draft BGP VPLS Flush October 2008
1. Introduction
[RFC4761] describes mechanisms that allow VPLS PEs to use BGP to
automatically discover PE membership in VPLS domains and to signal
pseudowires required to carry VPLS traffic. Each VPLS PE maintains
state for MAC addresses that it learns from locally attached customer
sites. In addition, each VPLS PE also maintains state for MAC
addresses that belong to remote customer sites that are attached to
remote PEs. MAC addresses of remote customer sites are learned over
the pseudowires that are established among all the VPLS PEs. In case
of a topology change that teardown pseudowires, VPLS PEs delete MAC
addresses that were learned on those pseudowires. However, there are
cases when a topology change, such as a failure between a customer
site and a PE, does not teardown a pseudowire. In such cases where
only local VPLS PE is aware of the topology change, an explicit
notification for flushing MAC addresses on remote VPLS PEs is
required. In absence of explicit MAC flush notification, stale MAC
state might be deleted when MAC age out timer expires, which is
typically in the order of minutes. Flushing of MAC addresses
increases connectivity restoration time after a failure, and thus, a
mechanism to expedite flushing of MAC addresses is highly desirable.
This document describes a new BGP Capability for flush mechanisms in
BGP based VPLS. A new BGP message, VPLS-FLUSH, is introduced to
carry a list of TLVs that will be used to flush the MAC addresses
associated with those TLVs.
BGP is used as the control plane protocol to carry the VPLS-FLUSH
message for following reasons:
1. Reuse: Since BGP is already used as the control plane protocol
for VPLS service, use of BGP to carry VPLS-FLUSH message
eliminates need for service providers to deploy a new protocol
for MAC flush notification.
2. Efficient flooding: Since a VPLS PE that triggers the MAC flush
operations needs to notify all other VPLS PEs participating in
the same VPLS, it needs to efficiently flood the message to only
the PEs that are intended recipient of VPLS-FLUSH message. The
VPLS-FLUSH message will be propagated to only those routers that
would have received the VPLS NLRIs for the same RT that is
carried in the VPLS-FLUSH message as well, both in intra-AS and
inter-AS deployments. BGP signalled VPLS networks restrict the
flow of routing messages to only the interested routers and ASes
today by use of Route Target extended communities [RFC4360] and
RT constrains [RFC4684].
Kothari & Fernando Expires April 30, 2009 [Page 3]
Internet-Draft BGP VPLS Flush October 2008
1.1. General Terminology
VPLS domain: A VPLS domain represents a bridging domain per customer.
A Route Target community as described in [RFC4360] is used to
identify all the PE routers participating in a particular VPLS
domain.
Source PE: A VPLS PE that originates either the VPLS NLRI or VPLS-
FLUSH message. The source PE address is carried in Route Origin
Extended Community [RFC4360] and use of this community for VPLS
advertisements is described in [I-D.kompella-l2vpn-vpls-multihoming].
1.2. 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].
Kothari & Fernando Expires April 30, 2009 [Page 4]
Internet-Draft BGP VPLS Flush October 2008
2. VPLS Flush Capability
To advertise the VPLS Flush Capability to a peer, a BGP speaker uses
BGP Capabilities Advertisement [RFC3392]. The Capability code is to
be assigned by IANA with a Capability length 0.
By advertising the VPLS Flush Capability to a peer, a BGP speaker
conveys to the peer that the speaker is capable of receiving and
properly handling the VPLS-FLUSH message, described in Section 4,
from the peer.
A BGP speaker should only send a VPLS Flush Capability to a peer if
and only if BGP VPLS address family (Section 3.2.2 [RFC4761]) is also
enabled and negotiated with the peer.
Kothari & Fernando Expires April 30, 2009 [Page 5]
Internet-Draft BGP VPLS Flush October 2008
3. VPLS-FLUSH Message
The VPLS-FLUSH is a new BGP message that always includes the fixed
size BGP header and MUST include the fields shown below. The type is
to be assigned by IANA.
Message Format:
+-----------------------------------------------------+
| Sequence Number (4 octets) |
+-----------------------------------------------------+
| Total Path Attribute Length (2 octets) |
+-----------------------------------------------------+
| Path Attributes (variable) |
+-----------------------------------------------------+
| VPLS Flush TLVs Length (2 octets) |
+-----------------------------------------------------+
| VPLS Flush TLVs (variable) |
+-----------------------------------------------------+
Sequence Number:
This 4-octets unsigned integer indicates the current
sequence number of the flush message being sent to the
remote VPLS PEs.
Total Attribute Length:
This 2-octets unsigned integer indicates the total
length of the Path Attributes field in octets. Its
value MUST be greater than 0, which implies that at
least one attribute must be present.
Attributes:
A variable length sequence of path attributes is
present in every VPLS-FLUSH message. The following
attributes MUST be present:
o Route Target Community
o AS-PATH Attribute
o ORIGINATOR_ID Attribute
Kothari & Fernando Expires April 30, 2009 [Page 6]
Internet-Draft BGP VPLS Flush October 2008
o CLUSTER_LIST Attribute
o Route Origin Extended Community
AS-PATH, ORIGINATOR_ID and CLUSTER_LIST attributes
are processed and updated exactly like they are in
routing messages and are present to make sure
VPLS-FLUSH messages never end up in a loop. Note
that use of Route Origin Extended Community for
VPLS advertisements is described in
[I-D.kompella-l2vpn-vpls-multihoming].
VPLS Flush TLVs Length:
This 2-octets unsigned integer indicates the total
length of the VPLS Flush TLVs field in octets.
Its value MUST be greater than 0.
VPLS Flush TLVs:
This is a variable length field that contains a
list of TLVs that indicates what MAC addresses are
to be flushed based on the value contained in each
TLV. Each TLV is a triple <type, length, value> of
variable length. The type is a 2-octet field that
identifies one of the possible TLVs defined.
Length is a 2-octet field that indicates the TLV
value length. Value is of variable length and is
encoded according to the TLV type.
If a VPLS PE receives a VPLS-FLUSH message that
contains a TLV type that it does not understand,
it SHOULD ignore that TLV alone.
The Type is a 2-octet field, with possible values
as follows:
Value Meaning
0 MAC list TLV
Kothari & Fernando Expires April 30, 2009 [Page 7]
Internet-Draft BGP VPLS Flush October 2008
3.1. MAC List TLV
VPLS FLush TLV type 0 indicates that the TLV contains a list of 48
bits MAC addresses that should be flushed by the PE processing the
VPLS-FLUSH message.
The length field specifies the total length in octets of the MAC
addresses present in the TLV. If the length is 0, which indicates
that no MAC addresses are present, then all MAC addresses learned
from the source PE (indicated by Route Origin Extended Community)
should be flushed. The length MUST be a multiple of 6.
The encoding for MAC list 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 | Length |
+------------------------------+-------------------------------+
| MAC address #1 |
+------------------------------+-------------------------------+
| MAC address #1 | MAC address #2 |
+------------------------------+-------------------------------+
| MAC address #2 |
+------------------------------+-------------------------------+
. ... .
+------------------------------+-------------------------------+
| MAC address #n |
+------------------------------+-------------------------------+
| MAC address #n |
+------------------------------+
A VPLS PE that receives a VPLS-FLUSH message with a MAC list TLV
should delete each MAC address listed in the TLV that it learned from
the source VPLS PE for the VPLS domain specified by the Route Target.
Kothari & Fernando Expires April 30, 2009 [Page 8]
Internet-Draft BGP VPLS Flush October 2008
4. Operation
A speaker that is willing to receive the VPLS-FLUSH message from its
peer should advertise the VPLS-FLUSH capability to its peer.
A speaker may send the VPLS-FLUSH message to its peer only if it has
received the VPLS-FLUSH capability from its peer.
A VPLS-FLUSH message originated for a particular VPLS domain should
carry the same Route Target (RT) that is used to identify that VPLS
domain. The Route Target Extended Communities serve the dual purpose
of identifying the member PEs of a VPLS domain as well as limiting
the flooding of the VPLS-FLUSH message to be bounded by the member
PEs. A router that receives a VPLS-FLUSH message without any RTs
MUST neither process it nor propagate it.
A RR or ASBR should not do BGP path selection for VPLS-FLUSH
messages. A RR or ASBR MUST process the attributes contained in the
VPLS-FLUSH message for loop detection and for RT constrains before
propagating the message to other BGP peers, but it should hold no
permanent state for a VPLS-FLUSH message.
A PE should not do BGP or VPLS path selection for VPLS-FLUSH
messages. A PE should only process VPLS Flush TLVs for the messages
that have Route Target that matches one of the VPLS instance
configured on the PE router. A PE might receive the same VPLS-FLUSH
message from a source PE more than once due to presence of RRs or
ASBRs. A PE can use the sequence number field to detect duplicate
VPLS-FLUSH messages. It is RECOMMENDED that a PE ignore duplicate
VPLS-FLUSH messages. How a PE ignore duplicate VPLS-FLUSH messages
is outside the scope of this document. Other than state to detect
duplicate flush messages, a PE should hold no other permanent state.
A VPLS-FLUSH message might be lost if there are multiple failures.
In such cases, the remote PEs for which the flush message was
targeted for will continue to hold stale information unless they age
it out or relearn the MAC addresses from a different source PE. If a
VPLS-FLUSH message is lost due to a topology change that also
teardown the PWs, then the affected PEs SHOULD flush MAC addresses
learned over those PWs.
Kothari & Fernando Expires April 30, 2009 [Page 9]
Internet-Draft BGP VPLS Flush October 2008
5. Security Considerations
TBD
Kothari & Fernando Expires April 30, 2009 [Page 10]
Internet-Draft BGP VPLS Flush October 2008
6. IANA Considerations
TBD
Kothari & Fernando Expires April 30, 2009 [Page 11]
Internet-Draft BGP VPLS Flush October 2008
7. Acknowledgments
The authors would like to thank Yakov Rekhter, Nischal Sheth and John
Scudder for their comments and suggestions.
Kothari & Fernando Expires April 30, 2009 [Page 12]
Internet-Draft BGP VPLS Flush October 2008
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
[I-D.kompella-l2vpn-vpls-multihoming]
Kompella, K., Kothari, B., and T. IV, "Multi-homing in
BGP-based Virtual Private LAN Service",
draft-kompella-l2vpn-vpls-multihoming-01 (work in
progress), July 2008.
8.2. Informative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
Capability for BGP-4", RFC 5291, August 2008.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006.
[802.1ah] "IEEE Draft P802.1ah/D4.2 Virtual Bridged Local Area
Networks, Amendment 6: Provider Backbone Bridges,",
March 2008.
Kothari & Fernando Expires April 30, 2009 [Page 13]
Internet-Draft BGP VPLS Flush October 2008
Authors' Addresses
Bhupesh Kothari
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: bhupesh@juniper.net
Rex Fernando
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: rex@juniper.net
Kothari & Fernando Expires April 30, 2009 [Page 14]
Internet-Draft BGP VPLS Flush October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Kothari & Fernando Expires April 30, 2009 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-21 12:00:59 |