draft-ietf-bess-bgp-vpls-control-flags-08.txt   rfc8614.txt 
BESS Working Group R. Singh Internet Engineering Task Force (IETF) R. Singh
INTERNET-DRAFT K. Kompella Request for Comments: 8614 K. Kompella
Intended Status: Proposed Standard Juniper Networks Updates: 4761 Juniper Networks
Updates: 4761 (if approved) S. Palislamovic Category: Standards Track S. Palislamovic
Nokia ISSN: 2070-1721 Nokia
Expires: October 20, 2019 April 18, 2019 June 2019
Updated processing of Control Flags for BGP VPLS Updated Processing of Control Flags for
draft-ietf-bess-bgp-vpls-control-flags-08 BGP Virtual Private LAN Service (VPLS)
Abstract Abstract
This document updates the meaning of the Control Flags field in the This document updates the meaning of the Control Flags field in the
Layer2 Info Extended Community used for BGP-VPLS NLRI as defined in "Layer2 Info Extended Community" used for BGP Virtual Private LAN
RFC4761. This document updates RFC4761. Service (VPLS) Network Layer Reachability Information (NLRI) as
defined in RFC 4761. This document updates RFC 4761.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8614.
Copyright and License Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Description .............................................3
3 Updated meaning of Control Flags in the Layer2 Info Extended 3. Updated Meaning of Control Flags in the Layer2 Info Extended
Community . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Community .......................................................3
3.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 4 3.1. Control Word (C-Bit) .......................................4
3.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 4 3.2. Sequence Flag (S-Bit) ......................................4
4 Using Point-to-MultiPoint (P2MP) LSPs as transport for BGP 4. Using Point-to-Multipoint (P2MP) LSPs as Transport for
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 BGP VPLS ........................................................5
5 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6 5. Illustrative Diagram ............................................6
6 Treatment of C and S bits in multi-homing scenarios . . . . . . 7 6. Treatment of C-Bits and S-Bits in Multihoming Scenarios .........7
6.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 7 6.1. Control Word (C-Bit) .......................................7
6.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 7 6.2. Sequence Flag (S-Bit) ......................................7
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations .........................................8
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations .............................................8
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References ......................................................8
9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References .......................................8
9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References .....................................9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses .................................................9
1 Introduction 1. Introduction
"Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling" ([RFC4761]) describes the concepts and signaling for using Signaling" [RFC4761] describes the concepts and signaling for using
Border Gateway Protocol (BGP) to setup a VPLS. It specifies the BGP the Border Gateway Protocol (BGP) to set up a VPLS. It specifies the
VPLS Network Layer Reachability Information (NLRI) by which a BGP VPLS Network Layer Reachability Information (NLRI) by which a
provider-edge router (PE) may require other PEs in the same VPLS to Provider Edge (PE) router may require other PEs in the same VPLS to
include (or not) the control-word and sequencing information in VPLS include (or not) the Control Word (CW) and sequencing information in
frames sent to this PE. VPLS frames sent to this PE.
The use of the Control Word (CW) helps prevent mis-ordering of IPv4 The use of the CW helps prevent the misordering of IPv4 or IPv6
or IPv6 Pseudo-Wire (PW) traffic over Equal Cost Multi-Path (ECMP) Pseudowire (PW) traffic over Equal-Cost Multipath (ECMP) paths or
paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes Link Aggregation Group (LAG) bundles. [RFC4385] describes the format
the format for CW that may be used over Point-to-Point PWs and over a for the CW that may be used over point-to-point PWs and over a VPLS.
VPLS. Along with [RFC3985], the document also describes sequence Along with [RFC3985], [RFC4385] also describes sequence number usage
number usage for VPLS frames. for VPLS frames.
However, [RFC4761] does not specify the behavior of PEs in a mixed However, [RFC4761] does not specify the behavior of PEs in a mixed
environment where some PEs support Control Word/sequencing and others environment where some PEs support CW/sequencing and others do not.
do not.
1.1 Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2 Problem 2. Problem Description
[RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises [RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises
the behavior expected by the multiple PEs participating in the same the behavior expected by the multiple PEs participating in the same
VPLS. The NLRI indicates the VPLS label that the various PE routers, VPLS. The NLRI indicates the VPLS label that the various PE routers,
which are referred to in the NLRI, should use when forwarding VPLS which are referred to in the NLRI, should use when forwarding VPLS
traffic to this PE. Additionally, by using the Control Flags this PE traffic to this PE. Additionally, by using the Control Flags, this
specifies whether the other PEs (in the same VPLS) should use Control PE specifies whether the other PEs (in the same VPLS) should use the
Word or sequenced-delivery for frames forwarded to this PE. These are CW or sequenced delivery for frames forwarded to this PE. These are
respectively indicated by the C and the S bits in the Control Flags indicated by the C-bits and the S-bits, respectively, in the Control
as specified in section 3.2.4 in [RFC4761]. Flags, as specified in Section 3.2.4 in [RFC4761].
[RFC4761] requires that if the advertising PE sets the C and S bits, [RFC4761] requires that if the advertising PE sets the C-bits and
the receiving PE MUST, respectively, insert control word (CW) and S-bits, the receiving PE MUST, respectively, insert a CW and include
include sequence numbers when forwarding VPLS traffic to the sequence numbers when forwarding VPLS traffic to the advertising PE.
advertising PE.
However, in a BGP VPLS deployment there would often be cases where a However, in a BGP VPLS deployment, there would often be cases where a
PE receiving the VPLS BGP NLRI may not have the ability to insert a PE receiving the VPLS BGP NLRI may not have the ability to insert a
CW or include sequencing information inside PW frames. Thus, the CW or include sequencing information inside PW frames. Thus, the
behavior of processing CW and sequencing needs to be further behavior of CW processing and sequencing needs to be further
specified. specified.
This document updates the meaning of the Control Flags in layer2 This document updates the meaning of the Control Flags in the Layer2
extended community in the BGP VPLS NLRI. It also specifies the Info Extended Community in the BGP VPLS NLRI. It also specifies the
forwarding behavior for a mixed-mode environment where not every PE forwarding behavior for a mixed-mode environment where not every PE
in a VPLS has the ability or the configuration to honor the control in a VPLS has the ability or the configuration to honor the Control
flags received from the PE advertising the BGP NLRI. Flags received from the PE advertising the BGP NLRI.
3 Updated meaning of Control Flags in the Layer2 Info Extended 3. Updated Meaning of Control Flags in the Layer2 Info Extended
Community Community
The current specification does not allow for the CW setting to be [RFC4761] does not allow for the CW setting to be negotiated. In a
negotiated. In a typical implementation, if a PE sets the C-bit, it typical implementation, if a PE sets the C-bit, it expects to receive
expects to receive VPLS frames with a control word, and will send VPLS frames with a CW and will send frames the same way. If the PEs
frames the same way. If the PEs at the two ends of a PW do not agree at the two ends of a PW do not agree on the setting of the C-bit, the
on the setting of the C-bit, the PW does not come up. The behavior PW does not come up. The behavior is similar for the S-bit.
is similar for the S-bit.
This memo updates the meaning of the C-bit and the S-bit in the This memo updates the meaning of the C-bit and the S-bit in the
control flags. Control Flags.
3.1 Control word (C-bit) 3.1. Control Word (C-Bit)
If a PE sets the C-bit in its NLRI, it means that the PE has ability If a PE sets the C-bit in its NLRI, it means that the PE has the
to send and receive frames with a control word. If the PEs at both ability to send and receive frames with a CW.
ends of a PW set the C-bit, control words MUST be used in both
directions of the PW. If both PEs send a C-bit of 0, Control Words - If the PEs at both ends of a PW set the C-bit, CWs MUST be used in
MUST NOT be used on the PW. These two cases behave as before. both directions of the PW.
- If both PEs send a C-bit of 0, CWs MUST NOT be used on the PW.
These two cases behave as before.
However, if the PEs at both ends of the PW do not agree on the However, if the PEs at both ends of the PW do not agree on the
setting of the C-bit, control words MUST NOT be used in either setting of the C-bit, CWs MUST NOT be used in either direction on
direction on that PW but the PW MUST NOT be prevented from coming up that PW, but the PW MUST NOT be prevented from coming up due to this
due to this mismatch. So, the PW will still come up but not use mismatch. So, the PW will still come up but will not use the CW in
control word in either direction. This behavior is changed from the either direction. This behavior is changed from the behavior
behavior described in [RFC4761] where the PW does not come up. described in [RFC4761] where the PW does not come up.
3.2 Sequence flag (S-bit) 3.2. Sequence Flag (S-Bit)
If a PE sets the S-bit in its NLRI, it means that the PE has ability If a PE sets the S-bit in its NLRI, it means that the PE has the
to set sequence numbers as listed in section 4.1 in [RFC4385] and ability to set sequence numbers as described in Section 4.1 in
process sequence numbers as listed in section 4.2 in [RFC4385]. If [RFC4385] and process sequence numbers as described in Section 4.2 in
the PEs at both ends of a PW set the S-bit, non-zero sequence numbers [RFC4385].
MUST be used in both directions of the PW. If both PEs send a S-bit
of 0, sequence numbers MUST NOT be used on the PW. These two cases
behave as before.
Current BGP VPLS specification does not allow for S-bit setting to be - If the PEs at both ends of a PW set the S-bit, non-zero sequence
negotiated either. In a typical implementation, if the PE sets the numbers MUST be used in both directions of the PW.
S-bit in the advertised NLRI, it expects to receive VPLS frames with
non-zero sequence numbers, and will send outgoing frames over the PW - If both PEs send an S-bit of 0, sequence numbers MUST NOT be used
with non-zero sequence numbers. on the PW.
These two cases behave as before.
[RFC4761] does not allow for the S-bit setting to be negotiated
either. In a typical implementation, if the PE sets the S-bit in the
advertised NLRI, it expects to receive VPLS frames with non-zero
sequence numbers and will send outgoing frames over the PW with
non-zero sequence numbers.
This memo further specifies the expected behavior when the PEs at the This memo further specifies the expected behavior when the PEs at the
ends of the PW advertise differing S-bit values. If the PEs at both ends of the PW advertise differing S-bit values. If the PEs at both
ends of the PW do not agree on the setting of the S-bit, then the PW ends of the PW do not agree on the setting of the S-bit, then the PW
SHOULD NOT come up. This is to avoid running into out-of-sequence SHOULD NOT come up. This is to avoid running into out-of-sequence
ordering scenarios when the multiple PEs that are enabling multi- ordering scenarios when the multiple PEs that are enabling
homing for a site have differing S-bit advertisements as listed in multihoming for a site have differing S-bit advertisements as
section 4.2 in [RFC4385]. However, if a deployment is known to not described in Section 4.2 in [RFC4385]. However, if a deployment is
utilize multi-homing, a user-configurable way to override this known to not utilize multihoming, a user-configurable way to override
recommendation MAY BE provided by an implementation whereby the PW is this recommendation MAY be provided by an implementation whereby the
allowed to come up. In that case the PE advertising S-bit as 0 should PW is allowed to come up. In that case, the PE advertising the S-bit
set sequence numbers in the frames as zero and the PW receiving the as 0 should set sequence numbers in the frames as 0, and the PW
frames should not have an expectation to receive non-zero sequence receiving the frames should not expect to receive non-zero sequence
numbers. numbers.
4 Using Point-to-MultiPoint (P2MP) LSPs as transport for BGP VPLS 4. Using Point-to-Multipoint (P2MP) LSPs as Transport for BGP VPLS
BGP VPLS can be used over point-2-point LSPs acting as transport BGP VPLS can be used over point-to-point Label Switched Paths (LSPs)
between the VPLS PEs. Alternately, BGP VPLS may also be used over acting as transport between the VPLS PEs. Alternately, BGP VPLS may
P2MP Label Switched Path (LSPs) with the source of the P2MP LSP also be used over Point-to-Multipoint (P2MP) LSPs with the source of
rooted at the PE advertising the VPLS BGP NLRI. the P2MP LSP rooted at the PE advertising the VPLS BGP NLRI.
In a network that uses P2MP LSPs as transport for a VPLS, there may In a network that uses P2MP LSPs as transport for a VPLS, there may
be some PEs that support CW while others may not. Similarly, for the be some PEs that support the CW while others may not. The behavior
sequencing of VPLS frames. is similar for the sequencing of VPLS frames.
In such a setup, a source PE that supports CW should setup two In such a setup, a source PE that supports CW should set up two
different P2MP LSPs such that: different P2MP LSPs such that:
- One P2MP LSP will transport CW-marked frames to those PEs
that advertised the C-bit as 1.
- The other P2MP LSP will transport frames without CW to those
PEs that advertised C-bit as 0.
Using two different P2MP LSPs to deliver frames with and without - One P2MP LSP will transport CW-marked frames to those PEs that
the CW to different PEs ensures that a P2MP root PE honors the C- advertised the C-bit as 1.
bit advertised by the other P2MP PEs.
However, the set of leaves on the two P2MP LSPs (rooted at the - The other P2MP LSP will transport frames without the CW to those
given PE) MUST NOT contain any PEs that advertised a value for the PEs that advertised the C-bit as 0.
S-bit different from what the root PE itself is advertising. PEs
that advertised their S-bit value differently (from what the P2MP
root PE advertised) will not be on either of the P2MP LSPs. This
ensures that the P2MP root PE is sending VPLS frames only to those
PEs that agree on the setting of S-bit.
The ingress router for the P2MP LSP should send separate NLRIs for Using two different P2MP LSPs to deliver frames with and without the
the cases of using control-word and for not using control-word. CW to different PEs ensures that a P2MP root PE honors the C-bit
advertised by the other P2MP PEs.
5 Illustrative diagram However, the set of leaves on the two P2MP LSPs (rooted at the given
PE) MUST NOT contain any PEs that advertised a value for the S-bit
different from what the root PE itself is advertising. PEs that
advertised their S-bit values differently (from what the P2MP root PE
advertised) will not be on either of the P2MP LSPs. This ensures
that the P2MP root PE is sending VPLS frames only to those PEs that
agree on the setting of the S-bit.
The ingress router for the P2MP LSP should send separate NLRIs for
the cases of using the CW and for not using the CW.
5. Illustrative Diagram
----- -----
/ A1 \ / A1 \
---- ____CE1 | ---- ____CE1 |
/ \ -------- -------- / | | / \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
\ / \ / \___/ | \ ----- \ / \ / \___/ | \ -----
---- ---PE2 | \ ---- ---PE2 | \
| | \ ----- | | \ -----
| Service Provider Network | \ / \ | Service Provider Network | \ / \
skipping to change at page 6, line 32 skipping to change at page 6, line 27
| ___ | / \ / | ___ | / \ /
\ / \ PE4_/ ----- \ / \ PE4_/ -----
PE3 / \ / PE3 / \ /
|------/ \------- ------- |------/ \------- -------
---- / | ---- ---- / | ----
/ \/ \ / \ CE = Customer Edge Device / \/ \ / \ CE = Customer Edge Device
| A3 CE3 --CE4 A4 | PE = Provider Edge Router | A3 CE3 --CE4 A4 | PE = Provider Edge Router
\ / \ / \ / \ /
---- ---- A<n> = Customer site n ---- ---- A<n> = Customer site n
Figure 1: Example of a VPLS Figure 1: Example of a VPLS
In the above topology, let there be a VPLS configured with the PEs as In the above topology, let there be a VPLS configured with the PEs as
displayed. Let PE1 be the PE under consideration that is CW enabled displayed. Let PE1 be the PE under consideration that is CW enabled
and sequencing enabled. Let PE2 and PE3 also be CW enabled and and sequencing enabled. Let PE2 and PE3 also be CW enabled and
sequencing enabled. Let PE4 not be CW enabled or have the ability to sequencing enabled. Let PE4 not be CW enabled or have the ability to
include sequence numbers. PE1 will advertise a VPLS BGP NLRI, include sequence numbers. PE1 will advertise a VPLS BGP NLRI,
containing the C/S bits marked as 1. PE2 and PE3 on learning of NLRI containing the C/S-bits marked as 1. PE2 and PE3, on learning of the
from PE1, will include the CW and non-zero sequence numbers in the NLRI from PE1, will include the CW and non-zero sequence numbers in
VPLS frames being forwarded to PE1 as listed in section 4 in the VPLS frames being forwarded to PE1 as described in Section 4 in
[RFC4385]. However, PE4 which does not have the ability to include CW [RFC4385]. However, PE4, which does not have the ability to include
or include non-zero sequence numbers, will not. a CW or include non-zero sequence numbers, will not.
As per [RFC4761], PE1 would have an expectation that all other PEs As per [RFC4761], PE1 would expect all other PEs to forward
forward CW-containing frames which have non-zero sequence numbers. CW-containing frames that have non-zero sequence numbers. That
That expectation cannot be met by PE4 in this example. Thus, as per expectation cannot be met by PE4 in this example. Thus, as per
[RFC4761], the PW between PE1 and PE4 does not come up. [RFC4761], the PW between PE1 and PE4 does not come up.
However, this document addresses how to support the mixed-CW and However, this document addresses how an implementation should support
mixed sequencing-ability of PEs described above. PE1 will not bring BGP VPLS in a network where a subset of the BGP VPLS PEs support the
up the PW with PE4 due to the S-bit mismatch, unless overridden by CW and/or frame sequencing. PE1 will not bring up the PW with PE4
local configuration on PE1 and PE4 as specified in section 3.2. If due to the S-bit mismatch, unless overridden by local configuration
PE4 instead was to advertise a C-bit of 0 and an S-bit of 1, then on PE1 and PE4 as specified in Section 3.2. If PE4 instead was to
despite the CW mismatch the PW between PE1 and PE4 would come up. advertise a C-bit of 0 and an S-bit of 1, then the PW between PE1 and
Additionally PE1 would setup its data-plane such that it will strip PE4 would come up despite the CW mismatch. Additionally, PE1 would
the CW only for those VPLS frames that are received from PEs that set up its data plane such that it will strip the CW only for those
have indicated their desire to receive CW marked frames. So, PE1 will VPLS frames that are received from PEs that have indicated their
setup its data plane to strip the CW only for VPLs frames received desire to receive CW-marked frames. So, PE1 will set up its data
from PE2 and PE3 and it will expect to process PW frames containing plane to strip the CW only for VPLS frames received from PE2 and PE3,
non-zero sequence numbers as listed in section 4.2 in [RFC4385]. PE1 and it will expect to process PW frames containing non-zero sequence
will setup its data-plane to not strip the CW from frames received numbers as described in Section 4.2 in [RFC4385]. PE1 will set up
from PE4 and it it would expect PE4 to send frames with non-zero its data plane to not strip the CW from frames received from PE4, and
sequence numbers. All frames sent by PE4 to PE1 over the PW would it would expect PE4 to send frames with non-zero sequence numbers.
have a non-zero sequence number. All frames sent by PE4 to PE1 over the PW would have a non-zero
sequence number.
6 Treatment of C and S bits in multi-homing scenarios 6. Treatment of C-Bits and S-Bits in Multihoming Scenarios
6.1 Control word (C-bit) 6.1. Control Word (C-Bit)
In multi-homed environment, different PEs may effectively represent In a multihomed environment, different PEs may effectively represent
the same service destination end-point. It could be assumed that the the same service destination endpoint. It could be assumed that the
end-to-end PW establishment process should follow the same rules when end-to-end PW establishment process should follow the same rules when
it comes to control word requirement, meaning setting the C-bit would it comes to CW requirements, meaning that setting the C-bit would be
be enforced equally toward both primary and backup designated enforced equally toward both primary and backup designated
forwarders. forwarders.
However, in the multi-homing case each PW SHOULD be evaluated However, in the multihoming case, each PW SHOULD be evaluated
independently. Assuming the network topology specified in section 5, independently. Assuming the network topology specified in Section 5,
there could be the case where PW between PE2 and PE1 could have CW there could be the case where the PW between PE2 and PE1 could have
signaled via extended community and would be used in the VPLS frame, the CW signaled via the extended community and would be used in the
while PE2 to PE4 PW would not insert the CW in the VPLS frame due to VPLS frame, while the PE2-to-PE4 PW would not insert the CW in the
C-bit mismatch. The rest of PEs multi-homing behavior should simply VPLS frame due to a C-bit mismatch. The multihoming behavior of the
follow the rules specified in [VPLS-MULTIHOMING]. rest of the PEs should simply follow the rules specified in
[VPLS-MULTIHOMING].
6.2 Sequence flag (S-bit) 6.2. Sequence Flag (S-Bit)
In a multi-homed environment, different PEs may effectively represent In a multihomed environment, different PEs may effectively represent
the same service destination end-point. In this case, the rules for the same service destination endpoint. In this case, the rules for
end-to-end PW establishment SHOULD follow the same behavior as listed end-to-end PW establishment SHOULD follow the same behavior as that
in section 3.2 when it comes to sequence bit requirements. Consider described in Section 3.2 when it comes to S-bit requirements.
the case described in section 5 with CE5 being multi-homed to PE4 and Consider the case described in Section 5 with CE5 having a connection
PE1. The PW behavior is similar to the CW scenario so that the to multiple PEs (multihomed) to PE4 and PE1. The PW's behavior is
insertion of S-bit evaluation SHOULD be independent per PW. However, similar to that for the CW scenario such that the S-bit evaluation
because S-bit mismatch between two end-point PEs results in no PW SHOULD be independent per PW. So, in the case where PE4 does not set
establishment, in the case where PE4 doesn't support S-bit. So, only the S-bit in its advertised NLRI, there is an S-bit mismatch between
one PW would be established, between PE1 and PE2. Thus, even though PE1 and PE4. This mismatch prevents the PW establishment between PE1
CE5 is physically multi-homed, due to PE4's lack of support for and PE4. So, only one PW -- between PE1 and PE2 -- would be
sending frames with non-zero sequence numbers there would be no PW established for the multihomed site shown. Thus, even though CE5 is
between PE2 and PE4. CE5 would effectively not be multi-homed. physically multihomed, due to PE4's lack of support for sending
frames with non-zero sequence numbers, there would be no PW between
PE2 and PE4. CE5 would effectively not be multihomed.
7 Security Considerations 7. Security Considerations
This document updates the behavior specified in [RFC4761]. The This document updates the behavior specified in [RFC4761]. The
security considerations listed in [RFC4761] apply. This document security considerations discussed in [RFC4761] apply. This document
essentially addresses BGP-VPLS behavior for PEs when the C-bit and/or essentially addresses BGP VPLS behavior for PEs when the C-bit value,
S-bit value advertised by a given PE are different from what another the S-bit value, or both values advertised by a given PE are
PE in the VPLS is advertising. Any bit-flipping media errors leading different from what another PE in the VPLS is advertising. Any
to causing this mismatch of C/S bits between PEs do not adversely bit-flipping media errors leading to causing this mismatch of
affect the availability of the PWs. Rather they cause control-words C/S-bits between PEs do not adversely affect the availability of the
to not be used or cause the NRLI-advertising PE to not expect non- PWs. Rather, they cause CWs to not be used or cause the
zero sequenced frames, for the C-bit and the S-bit respectively being NLRI-advertising PE to not expect non-zero sequenced frames, for the
mismatched across PEs. This is no worse than the previous behavior C-bit and the S-bit, respectively, being mismatched across PEs. This
where any bit-flipping media errors leading to mismatch of C/S bit is no worse than the previous behavior where any bit-flipping media
between PEs would cause the PW to not come up. errors leading to a mismatch of the C/S-bits between PEs would cause
the PW to not come up.
8 IANA Considerations 8. IANA Considerations
This document does not make any requests from IANA. This document has no IANA actions.
9 References 9. References
9.1 Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
(VPLS) Using BGP for Auto-Discovery and Signaling, LAN Service (VPLS) Using BGP for Auto-Discovery and
RFC 4761, January 2007. Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC4385] Bryant, S., Swallow G., Martini L., D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
Pseudowire Emulation Edge-to-Edge (PWE3) Control Word, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, RFC 2119 Key Words", BCP 14, RFC 8174,
May 2017. DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
9.2 Informative References 9.2. Informative References
[RFC3985] Bryant, S., P. Pate, Pseudo Wire Emulation [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture, RFC3985, March 2005. Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>.
[VPLS-MULTIHOMING] Kothari, B., et al, BGP based Multi-homing in [VPLS-MULTIHOMING]
Virtual Private LAN Service, Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
draft-ietf-bess-vpls-multihoming-02, September 2018. and J. Uttaro, "BGP based Multi-homing in Virtual
Private LAN Service", Work in Progress,
draft-ietf-bess-vpls-multihoming-03, March 2019.
Authors' Addresses Authors' Addresses
Ravi Singh Ravi Singh
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US United States of America
EMail: ravis@juniper.net
Kireeti Kompella Email: ravis@juniper.net
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
US
EMail: kireeti@juniper.net
Senad Palislamovic Kireeti Kompella
Nokia Juniper Networks
600 Mountain Avenue 1133 Innovation Way
Murray Hill, NJ 07974-0636 Sunnyvale, CA 94089
US United States of America
EMail: Senad.palislamovic@nokia.com Email: kireeti@juniper.net
Senad Palislamovic
Nokia
600 Mountain Avenue
Murray Hill, NJ 07974-0636
United States of America
Email: Senad.palislamovic@nokia.com
 End of changes. 74 change blocks. 
262 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/