Internet DRAFT - draft-anshuverma-bess-vpls-best-site-id
draft-anshuverma-bess-vpls-best-site-id
Network Working Group
Internet-Draft
Intended status: Proposed Standard
Expires: November 2, 2016 A. Verma
Juniper Networks
J. Drake
Juniper Networks
R. Molina
Ericsson Inc.
W. Lin
Juniper Networks
May 2, 2016
Vpls Best-site id
draft-anshuverma-bess-vpls-best-site-id-02.txt
Abstract
With network-based applications becoming prevalent, solutions that
provide connectivity over wide area become more attractive for
customers. In small-to-medium enterprise sector, Virtual Private LAN
Service (VPLS), is a very useful service provider offering. It
creates an emulated LAN segments fully capable of learning and
forwarding Ethernet MAC addresses.
Today, in VPLS implementations, within the context of a VPLS PE (VE),
a single-site is selected from which all PWs are rooted. The site-
election mechanism is usually hard-coded by different vendors (e.g.
minimum or maximum site-id), and as such, is outside end-users
control. This offers no flexibility to end-users as it forces them to
define the site-id allocation scheme well in advance, or deal with
the consequences of a suboptimal site-id election. Moreover, whenever
the elected site-id is declared down, the traffic to and from all
other sites hosted within the same VE is impacted as well.
This draft defines protocol extensions to keep core-facing
pseudowires (PWs) established at all times, regardless of the events
Verma, et al [Page 1]
Internet-Draft VPLS Best-site ID May 2016
taking place on the attachment-circuit (AC) segment when using the
BGP-based signaling procedures.
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), 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 November 2, 2016.
Copyright Notice
Copyright (c) 2015 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 the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
[Page 2]
Internet-Draft VPLS Best-site ID May 2016
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................5
3. Modifications to Layer 2 Info Extended Community...............5
4. Best-site functionality........................................6
5. Remote mac-flush mechanism.....................................8
6. Security Considerations........................................9
7. IANA Considerations............................................9
8. References.....................................................9
8.1. Normative References......................................9
8.2. Informative References...................................10
9. Authors Addresses.............................................11
1. Introduction
As the popularity of VPLS services continue to expand, Service
Provider requirements for a scalable multi-homed solution are
becoming increasingly demanding. As dictated by RFC4762 BGP-VPLS RFC,
every PE participating in a VPLS domain must be fully meshed through
a bidirectional pseudowire (PW). This set of PWs is built attending
to the signaling information (label-block) advertised by each PE. The
label-block used to build any given PW, will be the one matching the
local site being elected as 'representative' of the VPLS domain
within a given PE. As stated in RFC4762, if this site is ever
declared 'down', a compliant implementation will need to either
withdraw the corresponding label-block, or announce that the affected
site is no longer reachable. In either case, the PW will end up being
destroyed, which will have a considerable impact on other local sites
relying on this specific PW. Furthermore, as a considerable amount of
cycles are spent in destroying/re-building affected PWs, the overall
convergence period will be severely impacted for those critical
multi-homed sites that need a rapid transition to a backup PE.
[Page 3]
Internet-Draft VPLS Best-site ID May 2016
This draft defines protocol extensions to keep core-facing
pseudowires established at all times, regardless of the events
taking place on the attachment-circuit segment when using the BGP-
based signaling procedures defined in [RFC4761].
Today, in VPLS implementations, within the context of a VPLS_PE (VE),
a single-site is selected from which all PWs are rooted. The site-
election mechanism is usually hard-coded by different vendors (e.g.
minimum or maximum site-id), and as such, is outside end-users
control. This offers no flexibility to end-users as it forces them to
define the site-id allocation scheme well in advance, or deal with
the consequences of a suboptimal site-id election. Moreover, whenever
the elected site-id is declared down, the traffic to and from all
other sites hosted within the same VE is impacted as well.
In BGP VPLS MH scenarios the above pitfalls are specially acute, as
not only we need to factor in the cost to bring the active PW down
and run DF election in primary PE, but also in the n-DF PE and all
remote-PEs within the VPLS domain. Taking into account that control-
plane operation is signaled through BGP protocol, is fare to expect
that many of these operations will be carried out in sequence and
not in parallel, so the overall cost is usually pretty considerable
in scaling scenarios.
To achieve minimal traffic disruption, this draft introduces a
virtual or dummy site which will serve as the preferable or best
site within each VE. Thereby, its corresponding site-id value will
be defined by the end-user. But more than providing greater
provisioning flexibility, the real advantage of this best-site
solution relies on the capability to maintain VPLS PWs established
at all times regardless of the fluctuations in AC segments.
To summarize, this best-site feature offers:
* Greater provisioning flexibility.
* Minimal traffic disruption for non-preferable sites in multi-
site VEs (upon AC going down).
* Convergence period would be considerably reduced in MH setups
during transient intervals.
[Page 4]
Internet-Draft VPLS Best-site ID May 2016
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 RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Modifications to Layer 2 Info Extended Community
The Layer 2 Info Extended Community is used to signal control
information of the pseudowires to be setup. The extended community
format is described in [RFC4761]. This draft recommends that the
Control Flags field of this extended community be used to synchronize
the best-site information amongst PEs for a given L2VPN.
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
Layer-2 Info Extended Community:
Control Flags Bit Vector:
This field contains bit flags relating to pseudowire's control
information. It is augmented with the definition of one new flag
field. If on a given PE VPLS instance is configured with 'best-
site', it will include in its VPLS BGP NLRI a Layer 2 Info Extended
Community using Control Flags field with B = 1.
[Page 5]
Internet-Draft VPLS Best-site ID May 2016
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|A|F|B|T|R|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+
With reference to the Control Flags Bit Vector, the following bits in
the Control Flags are defined; the remaining bits, MUST be set to
zero when sending and MUST be ignored when receiving this Extended
Community. The signaling procedure described here is therefore
backwards compatible with existing implementations.
D Defined in l2vpn-vpls-multihoming draft
A Defined in l2vpn-auto-site-id draft
F Defined in l2vpn-vpls-multihoming draft
B When the bit value is 1, the PE receiving the label-block
will deem the corresponding site as the most preferable site
from the remote neighbor.
When the bit value is 0, the PE receiving the label-block
will rely on its legacy/default site-election algorithm.
T/R Defined in l2vpn-fat-pw-bgp draft
C Defined in [RFC4761]
S Defined in [RFC4761]
4. Best-site functionality:
Traditionally, vpls path selection mechanism pick the minimum (or
maximum) site-id to determine the 'preferable' local site. This
'preferable' local site serves two purposes: 1) pseudowires created
from the local VE will be rooted from this site, and 2) pseudowires
created from remote VEs will be built towards this elected site.
[Page 6]
Internet-Draft VPLS Best-site ID May 2016
In order to provide some greater flexibility in the current pre-
defined site-election process, this draft proposes a solution to give
priority to these 'best-sites' in detriment of those local sites with
minimum (maximum) site-ids.
This solution would be fully backward compatible as VPLS-PEs on which
the proposed feature isn't enable, would simply obviate the BGP
extensions previously described, and thereby, would rely on their
legacy/default site-election mechanism.
Let's make use of the following example to describe our solution in
more details:
...............
. . ___ CE2
___ PE1 . /
/ : PE3
__/ : Service :
CE1 __ : Provider :
\ : :
\___ PE2 .
. .
...............
Figure 1- MH scenario with Best-site capable nodes.
A PE where 'best-site' feature is enabled in VPLS instance, behaves
as a dummy site and no access interface will be associated with it.
This dummy site won't be subjected to access interface down/up
events; thereby, the corresponding D-bit will not be set to represent
a site-down condition. The main goal here is to have a site that is
permanently alive, regardless of the state of the attached circuits
defined within the VPLS domain.
Each VPLS instance where a 'best-site' is defined (e.g. PE1), will
signal the site's existence by setting the B-bit of the control-
flags bit-vector within the L2-info extended community. Upon arrival
of this BGP advertisement to the receiving PE (e.g. PE3), and only
if this one is 'best-site' capable, the received B-bit will be
honored and the corresponding site will be elected as the most
preferable site within the remote VE (PE1).
[Page 7]
Internet-Draft VPLS Best-site ID May 2016
For those neighbors where 'best-site' feature is not configured,
conventional local site election will take place. For instance, if
PE1 does not receive a Label-Block advertisement with B-bit set from
a remote PE (PE3), it will assume that PE3 is not 'best-site'
capable, and will create a pseudowire from its minimum (maximum)
designated site. For the rest of the 'best-site' capable PEs, PE1
will construct pseudowires rooted at its 'best-site' site.
By proceeding to define a 'best-site' in each of the VEs across the
VPLS network, we will be drastically reducing the DF transition
period as no CPU cycles will need to be spent destroying and creating
new pseudowires during failover events.
5. Remote mac-flush requirement:
Having a permanent pseudowire setup would not be that effective if
we end up relying solely on the current implicit mac-flush
mechanism. MAC addresses are automatically aged out when the
pseudowire over which they are learned is deleted. This approach
would collide with the proposed 'best-site' feature, in which
pseudowires are kept established on a permanent basis.
An explicit-mac-flush capable implementation would ensure that MAC-
to-pseudowire bindings are cleared the moment in which a DF
transition is initiated. In scenarios where 'best-site' feature is
enabled, no core-facing PW will be ever torn down, so previously
learned MAC entries could potentially end up pointing to an invalid
PW.
Thereby, to avoid potential traffic blackholes, any successful
'best-site' implementation should be capable of supporting the
explicit-mac-flush mechanism depicted in [I-D.ietf-l2vpn-vpls-
multihoming draft]. F-bit was introduced in the Control-Flags
bit-vector, to provide a deterministic method in which any
given PE can request a remote PE to flush those mac-entries
learned from the former one.
Control Flags Bit Vector
[Page 8]
Internet-Draft VPLS Best-site ID May 2016
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|A|F|B|Z|Z|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+
When making use of this feature, a DF PE will set the 'F' bit,
whereas an n-DF one will clear it when sending BGP MH
advertisements. A state transition from one to zero for the 'F' bit,
will be interpreted by a remote PE as an indication to flush all the
MACs learned from the PE that is transitioning from DF to n-DF.
6. Security Considerations
This extension to BGP does not change the underlying security issues
inherent in the existing [RFC4271].
7. IANA Considerations
8. References
8.1. Normative References
[I-D.ietf-l2vpn-vpls-multihoming]
Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
Uttaro, J., Palislamovic, S., and W. Lin, "BGP based
Multi-homing in Virtual Private LAN Service",
draft-ietf-l2vpn-vpls-multihoming-07, May 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Page 9]
Internet-Draft VPLS Best-site ID May 2016
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN
Service(VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, January 2007.
8.2. Informative References
[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.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery
and Signaling", RFC 6624, May 2012.
[Page 10]
Internet-Draft VPLS Best-site ID May 2016
9. Author's Addresses
Anshu Verma
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
Email: anshuverma@juniper.net
John Drake
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
Email: jdrake@juniper.net
Rodny Molina
Ericsson Inc.
100 Headquarters Dr,
San Jose, CA 95134
Email: rodny.molina.maldonado@ericsson.com
Wen Lin
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
Email: wlin@juniper.net
[Page 11]
