draft-ietf-bess-bgp-vpls-control-flags-04.txt   draft-ietf-bess-bgp-vpls-control-flags-05.txt 
BESS Working Group R. Singh BESS Working Group R. Singh
INTERNET-DRAFT K. Kompella INTERNET-DRAFT K. Kompella
Intended Status: Proposed Standard Juniper Networks Intended Status: Proposed Standard Juniper Networks
S. Palislamovic Updates: RFC 4761 (once approved) S. Palislamovic
Alcatel-Lucent Alcatel-Lucent
Expires: August 20, 2018 February 16, 2018 Expires: January 3, 2019 July 2, 2018
Updated processing of control flags for BGP VPLS Updated processing of control flags for BGP VPLS
draft-ietf-bess-bgp-vpls-control-flags-04 draft-ietf-bess-bgp-vpls-control-flags-05
Abstract Abstract
This document updates the meaning of the "control flags" fields This document updates the meaning of the "control flags" fields
inside the "layer2 info extended community" used for BGP-VPLS NLRI. inside the "layer2 info extended community" used for BGP-VPLS NLRI as
defined in [RFC4761].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 21 skipping to change at page 2, line 22
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 p2mp LSP as transport for BGP VPLS . . . . . . . . . . . 5 4 Using p2mp LSP as transport for BGP VPLS . . . . . . . . . . . 5
5. Treatment of C and S bits in multi-homing scenarios . . . . . 5 5 Treatment of C and S bits in multi-homing scenarios . . . . . . 5
5.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 5 5.1 Control word (C-bit) . . . . . . . . . . . . . . . . . . . . 5
5.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 6 5.2 Sequence flag (S-bit) . . . . . . . . . . . . . . . . . . . 6
6 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6 6 Illustrative diagram . . . . . . . . . . . . . . . . . . . . . 6
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Introduction 1 Introduction
[RFC4761] describes the concepts and signaling for using BGP to setup [RFC4761] describes the concepts and signaling for using BGP (Border
a VPLS. It specifies the BGP VPLS NLRI that a PE may require other Gateway Protocol) to setup a VPLS (virtual private LAN service). It
PEs in the same VPLS to include (or not) control-word and sequencing specifies the BGP VPLS NLRI (network layer reachability information)
information in VPLS frames sent to this PE. by which a PE may require other PEs in the same VPLS to include (or
not) control-word and sequencing information in VPLS frames sent to
this PE.
The use of control word (CW) helps prevent mis-ordering of IPv4 or The use of control word (CW) helps prevent mis-ordering of IPv4 or
IPv6 PW traffic over ECMP-paths/LAG-bundles. [RFC4385] describes the IPv6 PW traffic over ECMP (equal cost multi-path) paths or LAG (link
format for control-word that may be used over point-2-point PWs and aggregation group) bundles. [RFC4385] describes the format for
over a VPLS. It along with [RFC3985] also describes sequencing of control-word that may be used over point-2-point PWs (pseudowires)
and over a VPLS. It along with [RFC3985] also describes sequencing of
frames. 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 control-word/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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2 Problem 2 Problem
[RFC4761] specifies the use of a VPLS BGP NLRI by which a given PE [RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises
advertises the required behavior off multiple PEs participating in the behavior expected from the multiple PEs participating in the same
the same VPLS. The behavior required off the multiple PEs identified VPLS. The NLRI indicates the VPLS label that the various PE routers,
by the NLRI indicates the VPLS label they should use in the VPLS which are referred to in the NLRI, should use when forwarding VPLS
traffic being forwarded to this PE. Additionally, by using the traffic to this PE. Additionally, by using the "control flags" this
"control flags" this PE specifies whether the other PEs (in the same PE specifies whether the other PEs (in the same VPLS) should use
VPLS) should use control-word or sequenced-delivery for frames control-word or sequenced-delivery for frames forwarded to this PE.
forwarded to this PE. These are respectively indicated by the C and These are respectively indicated by the C and the S bits in the
the S bits in the "control flags" as specified in section 3.2.4 in "control flags" as specified in section 3.2.4 in [RFC4761].
[RFC4761].
[RFC4761] requires that if the advertising PE sets the C and S bits, [RFC4761] requires that if the advertising PE sets the C and S bits,
the receiving PE MUST honor the same by inserting control word (CW) when forwarding VPLS traffic to the PE, the receiving PE MUST insert
and by including sequence numbers respectively. control word (CW) and by including sequence numbers respectively.
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 BGP VPLS needs to be further specified. behavior of processing CW and sequencing needs to be further
specified.
This document updates the meaning of the control flags in layer2 This document updates the meaning of the control flags in layer2
extended community in the BGP VPLS NLRI and specifies the resulting 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
Current specification does not allow for the CW setting to be Current specification does not allow for the CW setting to be
negotiated. Rather, if a PE sets the C-bit, it expects to receive negotiated. Rather, if a PE sets the C-bit, it expects to receive
VPLS frames with a control word, and will send frames the same way. VPLS frames with a control word, and will send frames the same way.
If the PEs at both ends of a pseudowire do not agree on the setting If the PEs at both ends of a pseudowire do not agree on the setting
skipping to change at page 4, line 36 skipping to change at page 4, line 40
MUST not be used on the PW. These two cases behave as before. MUST not be used on the PW. These two cases behave as before.
However, if the PEs don't agree on the setting of the C-bit, control However, if the PEs don't agree on the setting of the C-bit, control
words MUST not be used on that PW but the PW MUST NOT be prevented words MUST not be used on that PW but the PW MUST NOT be prevented
from coming up due to this mismatch. So, the PW MUST still come up. from coming up due to this mismatch. So, the PW MUST still come up.
This behavior is new; the old behavior was that the PW doesn't come This behavior is new; the old behavior was that the PW doesn't come
up. up.
3.2 Sequence flag (S-bit) 3.2 Sequence flag (S-bit)
Current BGP VPLS implementation do not allow for S-bit setting to be Current BGP VPLS specification do not allow for S-bit setting to be
negotiated either. If the PE sets the S-bit, it expects to receive negotiated either. If the PE sets the S-bit, it expects to receive
VPLS frames with sequence numbers, and will send the frames with the VPLS frames with sequence numbers, and will send the frames with
sequence numbers as well. This memo further specifies the existing sequence numbers as well. This memo further specifies the existing
behavior. If the PEs on the both ends of the PW set the S-bit, then behavior. If the PEs on the both ends of the PW set the S-bit, then
both PEs MUST include the PW sequence numbers. If the PEs at both both PEs MUST include the PW sequence numbers. If the PEs at both
ends of the PW do not agree on the setting of the S-bit, the PW ends of the PW do not agree on the setting of the S-bit, the PW
SHOULD NOT come up at all. SHOULD NOT come up at all.
4 Using p2mp LSP as transport for BGP VPLS 4 Using p2mp LSP 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-2-point LSPs acting as transport
between the VPLS PEs. Alternately, BGP VPLS may also be used over between the VPLS PEs. Alternately, BGP VPLS may also be used over
p2mp LSPs with the source of the p2mp LSP rooted at the PE p2mp (point to multipoint) LSPs (label switched path) with the source
advertising the VPLS BGP NLRI. of the p2mp LSP rooted at the PE advertising the VPLS BGP NLRI.
In a network that uses p2mp LSPs as transport for BGP VPLS, in a In a network that uses p2mp LSPs as transport for BGP VPLS, in a
given VPLS there may be some PEs that support control-word while given VPLS there may be some PEs that support control-word while
others do not. Similarly, for sequencing of frames. others do not. Similarly, for sequencing of frames.
In such a setup, a source PE that supports control-word should setup In such a setup, a source PE that supports control-word should setup
2 different p2mp LSPs such that: 2 different p2mp LSPs such that:
- one p2mp LSP will carry CW-marked frames to those PEs that - one p2mp LSP will carry CW-marked frames to those PEs that
advertised C-bit as 1, and advertised C-bit as 1, and
- the other p2mp LSP will carry frames without CW to those PEs - the other p2mp LSP will carry frames without CW to those PEs
that advertised C-bit as 0. that advertised C-bit as 0.
However, the set of leaves on the 2 p2mp LSPs (rooted at the given
PE) MUST NOT contain any PEs that advertised a value for S-bit
different from what this PE itself is advertising.
Using 2 different p2mp LSPs to deliver frames with and without CW Using 2 different p2mp LSPs to deliver frames with and without CW
to different PEs ensures that this PE honors the C-bit advertised to different PEs ensures that this PE honors the C-bit advertised
by the other PEs. by the other PEs.
By not having PEs that advertised their S-bit value differently However, the set of leaves on the 2 p2mp LSPs (rooted at the given
(from what this PE advertised) on either of the p2mp LSPs, it is PE) MUST NOT contain any PEs that advertised a value for S-bit
ensured that this PE is sending VPLS frames only to those PEs that different from what this PE itself is advertising. PEs that
agree on the setting of S-bit with this PE. advertised their S-bit value differently (from what this PE
advertised) will not be on either of the p2mp LSPs. It is ensured
that this PE is sending VPLS frames only to those PEs that agree
with this PE on the setting of S-bit.
5. Treatment of C and S bits in multi-homing scenarios 5 Treatment of C and S bits in multi-homing scenarios
5.1 Control word (C-bit) 5.1 Control word (C-bit)
In multi-homed environment, different PEs may effectively represent In multi-homed environment, different PEs may effectively represent
the same service destination end point. It could be assumed that the same service destination end point. It could be assumed that
the end-to-end PW establishment process should follow the same the end-to-end PW establishment process should follow the same
rules when it comes to control word requirement, meaning setting rules when it comes to control word requirement, meaning setting
the C-bit would be enforced equally toward both primary and backup the C-bit would be enforced equally toward both primary and backup
designated forwarder together. designated forwarder together.
However, it is to be noted that in the multi-homing case, each PW However, in the multi-homing case each PW SHOULD be evaluated
SHOULD be evaluated independently. Assuming the below specified independently. Assuming the below specified network topology, there
network topology, there could be the case where PW between PE2 and could be the case where PW between PE2 and PE1 could have control
PE1 could have control word signaled via extended community and word signaled via extended community and would be used in the VPLS
would be used in the VPLS frame, while PE2 to PE4 PW would not frame, while PE2 to PE4 PW would not insert the control word in the
insert the control word in the VPLS frame due to C-bit mismatch. VPLS frame due to C-bit mismatch. The rest of PEs multi-homing
The rest of PEs multi-homing behavior should simply follow the behavior should simply follow the rules specified in draft-ietf-
rules specified in draft-ietf-bess-vpls-multihoming-00. bess-vpls-multihoming-00.
5.2 Sequence flag (S-bit) 5.2 Sequence flag (S-bit)
In multi-homed environment, different PEs may effectively represent In multi-homed environment, different PEs may effectively represent
the same service destination end point. In this case, the rules the same service destination end point. In this case, the rules for
for end-to-end PW establishment SHOULD follow the same rules when end-to-end PW establishment SHOULD follow the same rules when it
it comes to sequence bit requirements. Consider the case below comes to sequence bit requirements. Consider the case below with
with CE5 being multi-homed to PE4 and PE1. The PW behavior is CE5 being multi-homed to PE4 and PE1. The PW behavior is similar
similar to the C-word scenario so that the insertion of S-bit to the C-word scenario so that the insertion of S-bit evaluation
evaluation SHOULD be independent per PW. However, because S-bit SHOULD be independent per PW. However, because S-bit mismatch
mismatch between two end-point PEs yields in no PW establishment, between two end-point PEs yields in no PW establishment, in the
in the case where PE4 doesn't support S-bit, only one PW would be case where PE4 doesn't support S-bit, only one PW would be
established, between PE1 and PE2. Thus, even though CE5 is established, between PE1 and PE2. Thus, even though CE5 is
physically multi-homed, due to PE4's lack of support for S-bit, and physically multi-homed, due to PE4's lack of support for S-bit, and
no PW between PE1 and PE4, CE5 would not be multi-homed any more. no PW between PE1 and PE4, CE5 would not be multi-homed any more.
6 Illustrative diagram 6 Illustrative diagram
----- -----
/ A1 \ / A1 \
---- ____CE1 | ---- ____CE1 |
/ \ -------- -------- / | | / \ -------- -------- / | |
skipping to change at page 7, line 26 skipping to change at page 7, line 24
CW mismatch. Additionally, it will setup its data-plane such that it CW mismatch. Additionally, it will setup its data-plane such that it
will strip the control-word only for those VPLS frames that are will strip the control-word only for those VPLS frames that are
received from PEs that are themselves indicating their desire to received from PEs that are themselves indicating their desire to
receive CW marked frames. So, PE1 will setup its data plane to strip- receive CW marked frames. So, PE1 will setup its data plane to strip-
off the CW only for VPLs frames received from PEs PE2 and PE3. PE1 off the CW only for VPLs frames received from PEs PE2 and PE3. PE1
will setup its data plane to not strip CW from frames received from will setup its data plane to not strip CW from frames received from
PE4. PE4.
7 Security Considerations 7 Security Considerations
No new security issues. This document updates the behavior specified in [RFC4761]. The
security considerations listed in [RFC4761] apply. However, there are
no new security considerations due to the text of this document.
8 IANA Considerations 8 IANA Considerations
None. This document does not make any requests from IANA.
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, March 1997.
[RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service [RFC4761] Kompella, K., Y. Rekhter, Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling, (VPLS) Using BGP for Auto-Discovery and Signaling,
 End of changes. 21 change blocks. 
58 lines changed or deleted 63 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/