draft-ietf-bess-fat-pw-bgp-03.txt   draft-ietf-bess-fat-pw-bgp-04.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Intended Status: Standard Track Arrcus Intended Status: Standard Track Arrcus
Updates: 4761 S. Boutros Updates: 4761 S. Boutros
VMware VMware
J. Liste J. Liste
Cisco Cisco
B. Wen B. Wen
Comcast Comcast
J. Rabadan J. Rabadan
Nokia Nokia
Expires: February 24, 2018 August 23, 2017 Expires: September 3, 2018 March 2, 2018
Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport
Labels Labels
draft-ietf-bess-fat-pw-bgp-03 draft-ietf-bess-fat-pw-bgp-04
Abstract Abstract
This draft defines protocol extensions required to synchronize flow This draft defines protocol extensions required to synchronize flow
label states among PEs when using the BGP-based signaling procedures. label states among Provider Edges PE(s) when using the BGP-based
These protocol extensions are equally applicable to point-to-point signaling procedures. These protocol extensions are equally
Layer2 Virtual Private Networks (L2VPNs). This draft updates RFC 4761 applicable to point-to-point Layer2 Virtual Private Networks
by defining new flags in the Control Flags field of the Layer2 Info (L2VPNs). This draft updates RFC 4761 by defining new flags in the
Extended Community. Control Flags field of the Layer2 Info Extended Community.
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 7 skipping to change at page 2, line 7
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (http://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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
Furthermore, [RFC6391] defines the LDP protocol extensions required Furthermore, [RFC6391] defines the LDP protocol extensions required
to synchronize the flow label states between the ingress and egress to synchronize the flow label states between the ingress and egress
PEs when using the signaling procedures defined in the [RFC8077]. PEs when using the signaling procedures defined in the [RFC8077].
A pseudowire (PW) [RFC3985] is transported over one single network A pseudowire (PW) [RFC3985] is transported over one single network
path, even if Equal Cost Multiple Paths (ECMPs) exist between the path, even if Equal Cost Multiple Paths (ECMPs) exist between the
ingress and egress PW provider edge (PE) equipment. This is required ingress and egress PW provider edge (PE) equipment. This is required
to preserve the characteristics of the emulated service. to preserve the characteristics of the emulated service.
This draft introduces an OPTIONAL mode of operation allowing to This draft introduces an optional mode of operation allowing to
transport a PW over ECMPs, for example when the use of these is known transport a PW over ECMPs, for example when the use of these is known
to be beneficial to the operation of the PW. This specification uses to be beneficial to the operation of the PW. This specification uses
the principles defined in [RFC6391], and augments the BGP-signaling the principles defined in [RFC6391], and augments the BGP-signaling
procedures of [RFC4761] and [RFC6624]. The use of a single path to procedures of [RFC4761] and [RFC6624]. The use of a single path to
preserve the packet delivery order remains the default mode of preserve the packet delivery order remains the default mode of
operation of a PW, and is described in [RFC4385] and [RFC4928]. operation of a PW, and is described in [RFC4385] and [RFC4928].
High bandwidth Ethernet-based services are a prime example that High bandwidth Ethernet-based services are a prime example that
benefits from the ability to load-balance flows in a PW over multiple benefits from the ability to load-balance flows in a PW over multiple
PSN paths. In general, load-balancing is applicable when the PW PSN paths. In general, load-balancing is applicable when the PW
skipping to change at page 5, line 44 skipping to change at page 5, line 44
|Z|Z|Z|Z|T|R|C|S| (Z = MUST Be Zero) |Z|Z|Z|Z|T|R|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: Control Flags Bit Vector Figure 2: Control Flags Bit Vector
With reference to the Control Flags Bit Vector, the following bits in With reference to the Control Flags Bit Vector, the following bits in
the Control Flags are defined; the remaining bits, designated Z, MUST the Control Flags are defined; the remaining bits, designated Z, MUST
be set to zero when sending and MUST be ignored when receiving this be set to zero when sending and MUST be ignored when receiving this
Extended Community. Extended Community.
T When the bit value is 1, the PE is requesting the ability T When the bit value is 1, the PE announce the ability
to send a Pseudowire packet that includes a flow label. to send a Pseudowire packet that includes a flow label.
When the bit value is 0, the PE is indicating that it will When the bit value is 0, the PE is indicating that it will
not send a Pseudowire packet containing a flow label. not send a Pseudowire packet containing a flow label.
R When the bit value is 1, the PE is able to receive a R When the bit value is 1, the PE is able to receive a
Pseudowire packet with a flow label present. When the bit Pseudowire packet with a flow label present. When the bit
value is 0, the PE is unable to receive a Pseudowire packet value is 0, the PE is unable to receive a Pseudowire packet
with the flow label present. with the flow label present.
C Defined in [RFC4761]. C Defined in [RFC4761].
skipping to change at page 6, line 30 skipping to change at page 6, line 30
A PE that wishes to send a flow label in a Pseudowire packet MUST A PE that wishes to send a flow label in a Pseudowire packet MUST
include in its VPLS BGP NLRI a Layer2 Info Extended Community using include in its VPLS BGP NLRI a Layer2 Info Extended Community using
Control Flags field with T = 1. Control Flags field with T = 1.
A PE that is willing to receive a flow label in a Pseudowire packet A PE that is willing to receive a flow label in a Pseudowire packet
MUST include in its VPLS BGP NLRI a Layer2 Info Extended Community MUST include in its VPLS BGP NLRI a Layer2 Info Extended Community
using Control Flags field with R = 1. using Control Flags field with R = 1.
A PE that receives a VPLS BGP NLRI containing a Layer2 Info Extended A PE that receives a VPLS BGP NLRI containing a Layer2 Info Extended
Community with R = 0 NUST NOT include a flow label in the Pseudowire Community with R = 0 MUST NOT include a flow label in the Pseudowire
packet. packet.
Therefore, a PE sending a Control Flags field with T = 1 and Therefore, a PE sending a Control Flags field with T = 1 and
receiving a Control Flags field with R = 1 MUST include a flow label receiving a Control Flags field with R = 1 MUST include a flow label
in the Pseudowire packet. Under all other combinations, a PE MUST in the Pseudowire packet. Under all other combinations, a PE MUST
NOT include a flow label in the Pseudowire packet. NOT include a flow label in the Pseudowire packet.
A PE MAY support the configuration of the flow label (T and R bits) A PE MAY support the configuration of the flow label (T and R bits)
on a per-service (e.g. VPLS VFI) basis. Furthermore, it is also on a per-service (e.g., VPLS VFI) basis. Furthermore, it is also
possible that on a given service, PEs may not share the same flow possible that on a given service, PEs may not share the same flow
label settings. The presence of a flow label is therefore determined label settings. The presence of a flow label is therefore determined
on a per-peer basis and according to the local and remote T and R bit on a per-peer basis and according to the local and remote T and R bit
values. For example, a PE part of a VPLS and with a local T = 1, values. For example, a PE part of a VPLS and with a local T = 1,
MUST only transmit traffic with a flow label to those peers that must only transmit traffic with a flow label to those peers that
signaled R = 1. And if the same PE has local R = 1, it MUST only signaled R = 1. And if the same PE has local R = 1, it must only
expect to receive traffic with a flow label from peers with T = 1. expect to receive traffic with a flow label from peers with T = 1.
Any other traffic MUST NOT have a flow label. A PE expecting to Any other traffic must not have a flow label. A PE expecting to
receive traffic from a remote peer with a flow label MAY drop traffic receive traffic from a remote peer with a flow label MAY drop traffic
that has no flow label. A PE expecting to receive traffic from a that has no flow label. A PE expecting to receive traffic from a
remote peer with no flow label MAY drop traffic that has flow label. remote peer with no flow label MAY drop traffic that has flow label.
Modification of flow label settings may impact traffic over a PW as Modification of flow label settings may impact traffic over a PW as
these could trigger changes in the PEs data-plane programming (i.e. these could trigger changes in the PEs data-plane programming (i.e.
imposition / disposition of flow label). This is an implementation imposition / disposition of flow label). This is an implementation
specific behavior and outside the scope of this draft. specific behavior and outside the scope of this draft.
The signaling procedures in [RFC4761] state that the unspecified bits The signaling procedures in [RFC4761] state that the unspecified bits
skipping to change at page 8, line 8 skipping to change at page 8, line 8
Layer2 Info Extended Community, it did not ask for the creation of a Layer2 Info Extended Community, it did not ask for the creation of a
registry. registry.
This document requests that IANA creates a registry for this bit This document requests that IANA creates a registry for this bit
vector and that it be called the "Layer2 Info Extended Community vector and that it be called the "Layer2 Info Extended Community
Control Flags Bit Vector" registry. Control Flags Bit Vector" registry.
This registry should be created here: This registry should be created here:
https://www.iana.org/assignments/bgp-extended-communities/bgp- https://www.iana.org/assignments/bgp-extended-communities/bgp-
extended-communities.xhtml extended-communities.xhtml.
The allocation policy for this registry is IETF Review as per
[RFC8126].
Considering [RFC4761] and this document, the initial registry is as Considering [RFC4761] and this document, the initial registry is as
follows: follows:
Value Name Reference Value Name Reference
----- -------------------------------- -------------- ----- -------------------------------- --------------
S Sequenced delivery of frames RFC4761 S Sequenced delivery of frames RFC4761
C Presence of a Control Word RFC4761 C Presence of a Control Word RFC4761
T Request to send a flow label This document T Request to send a flow label This document
R Ability to receive a flow label This document R Ability to receive a flow label This document
As per [RFC4761] and this document, the remaining bits are As per [RFC4761] and this document, the remaining bits are
unassigned, and MUST be set to zero when sending and MUST be ignored unassigned, and MUST be set to zero when sending and MUST be ignored
when receiving the Layer2 Info Extended Community. when receiving the Layer2 Info Extended Community.
7. Security Considerations 7. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
inherent in the existing [RFC4271]. inherent in the existing [RFC4271] and [RFC4761].
8. References 8. References
8.1. Normative References 8.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, DOI 10.17487/RFC2119, March Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <http://www.rfc-editor.org/info/rfc2119>. 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271,
January 2006, <http://www.rfc-editor.org/info/rfc4271>. January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over
an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006,
<http://www.rfc-editor.org/info/rfc4385>.
[RFC8077] Martini, L., and G. Heron, "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)", RFC 8077,
DOI 10.17487/RFC8077, February 2017, <http://www.rfc-
editor.org/info/rfc8077>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc- 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-
editor.org/info/rfc4761>. editor.org/info/rfc4761>.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI
10.17487/RFC4928, June 2007, <http://www.rfc-
editor.org/info/rfc4928>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over
an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391,
November 2011, <http://www.rfc-editor.org/info/rfc6391>. November 2011, <http://www.rfc-editor.org/info/rfc6391>.
[RFC8126] M. Cotton, et al., "Guidelines for Writing an IANA [RFC8126] M. Cotton, et al., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 8126, DOI 10.17487/RFC6391, June Considerations Section in RFCs", RFC 8126, DOI 10.17487/RFC6391, June
2017, <http://www.rfc-editor.org/info/rfc8126>. 2017, <http://www.rfc-editor.org/info/rfc8126>.
8.2. Informative References 8.2. Informative References
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985,
March 2005, <http://www.rfc-editor.org/info/rfc3985>. March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over
an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006,
<http://www.rfc-editor.org/info/rfc4385>.
[RFC8077] Martini, L., and G. Heron, "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)", RFC 8077,
DOI 10.17487/RFC8077, February 2017, <http://www.rfc-
editor.org/info/rfc8077>.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI
10.17487/RFC4928, June 2007, <http://www.rfc-
editor.org/info/rfc4928>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and Signaling", Virtual Private Networks Using BGP for Auto-Discovery and Signaling",
RFC 6624, DOI 10.17487/RFC6624, May 2012, <http://www.rfc- RFC 6624, DOI 10.17487/RFC6624, May 2012, <http://www.rfc-
editor.org/info/rfc6624>. editor.org/info/rfc6624>.
Authors' Addresses Authors' Addresses
Keyur Patel Keyur Patel
Arrcus Arrcus
Email: keyur@arrcus.com Email: keyur@arrcus.com
 End of changes. 15 change blocks. 
35 lines changed or deleted 32 lines changed or added

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