draft-ietf-bess-nsh-bgp-control-plane-14.txt   draft-ietf-bess-nsh-bgp-control-plane-15.txt 
BESS Working Group A. Farrel BESS Working Group A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended status: Standards Track J. Drake Intended status: Standards Track J. Drake
Expires: December 4, 2020 E. Rosen Expires: December 17, 2020 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
June 2, 2020 June 15, 2020
BGP Control Plane for the Network Service Header in Service Function BGP Control Plane for the Network Service Header in Service Function
Chaining Chaining
draft-ietf-bess-nsh-bgp-control-plane-14 draft-ietf-bess-nsh-bgp-control-plane-15
Abstract Abstract
This document describes the use of BGP as a control plane for This document describes the use of BGP as a control plane for
networks that support Service Function Chaining (SFC). The document networks that support Service Function Chaining (SFC). The document
introduces a new BGP address family called the SFC Address Family introduces a new BGP address family called the SFC Address Family
Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
two route types. One route type is originated by a node to advertise two route types. One route type is originated by a node to advertise
that it hosts a particular instance of a specified service function. that it hosts a particular instance of a specified service function.
This route type also provides "instructions" on how to send a packet This route type also provides "instructions" on how to send a packet
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2020. This Internet-Draft will expire on December 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://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
skipping to change at page 3, line 36 skipping to change at page 3, line 36
8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 57 8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 57
9. Security Considerations . . . . . . . . . . . . . . . . . . . 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 58
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 60 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 60
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 60 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 60
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 61 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 61
10.4. New SFP Association Type Registry . . . . . . . . . . . 61 10.4. New SFP Association Type Registry . . . . . . . . . . . 61
10.5. New Service Function Type Registry . . . . . . . . . . . 62 10.5. New Service Function Type Registry . . . . . . . . . . . 62
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 63 Community Sub-Types . . . . . . . . . . . . . . . . . . 63
10.7. New BGP Transitive Extended Community Type . . . . . . . 63 10.7. New BGP Transitive Extended Community Type . . . . . . . 64
10.8. New SFC Extended Community Sub-Types Registry . . . . . 64 10.8. New SFC Extended Community Sub-Types Registry . . . . . 64
10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 64 10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 64
10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 64 10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 65
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.1. Normative References . . . . . . . . . . . . . . . . . . 66 13.1. Normative References . . . . . . . . . . . . . . . . . . 66
13.2. Informative References . . . . . . . . . . . . . . . . . 67 13.2. Informative References . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
As described in [RFC7498], the delivery of end-to-end services can As described in [RFC7498], the delivery of end-to-end services can
skipping to change at page 8, line 27 skipping to change at page 8, line 27
SFPs within the network. It gathers information about the SFPs within the network. It gathers information about the
availability of SFIs and SFFs, instructs the control plane about the availability of SFIs and SFFs, instructs the control plane about the
SFPs to be programmed, and instructs the Classifiers how to assign SFPs to be programmed, and instructs the Classifiers how to assign
traffic flows to individual SFPs. traffic flows to individual SFPs.
2.2. Control Plane Overview 2.2. Control Plane Overview
To accomplish the function described in Section 2.1, this document To accomplish the function described in Section 2.1, this document
introduces the Service Function Type (SFT) that is the category of SF introduces the Service Function Type (SFT) that is the category of SF
that is supported by an SFF (such as "firewall"). An IANA registry that is supported by an SFF (such as "firewall"). An IANA registry
of Service Function Types is introduced in Section 10 and is of Service Function Types is introduced in Section 10.5 and is
consistent with types used in other work such as consistent with types used in other work such as
[I-D.dawra-idr-bgp-ls-sr-service-segments]. An SFF may support SFs [I-D.dawra-idr-bgp-ls-sr-service-segments]. An SFF may support SFs
of multiple different SFTs, and may support multiple SFIs of each SF. of multiple different SFTs, and may support multiple SFIs of each SF.
The registry of SFT values (see Section 10.5) is split into three
ranges with assignment policies per [RFC8126]:
o The Special Purpose SFT values range is assigned through Standards
Action. Values in that range are used for special SFC operations
and do not apply to the types SF that may be placed on the SFC.
o The First Come First Served range tracks assignments of STF values
made by any party that defines an SF type. Reference through an
Internet-Draft is desirable, but not required.
o The Private Use range is not tracked by IANA and is primarily
intended for use in private networks where the meaning of the SFT
values is locally tracked and under the control of a local
administrator.
It is envisaged that the majority of SFT values used will be assigned
from the First Come First Served space in the registry. This will
ensure interoperability especially in situations where software and
hardware from different vendors is deployed in the same networks, or
when networks are merged. However, operators of private networks may
choose to develop their own SFs and manage the configuration and
operation of their network through their own list of SFT values.
This document also introduces a new BGP AFI/SAFI (values to be This document also introduces a new BGP AFI/SAFI (values to be
assigned by IANA) for "SFC Routes". Two SFC Route Types are defined assigned by IANA) for "SFC Routes". Two SFC Route Types are defined
by this document: the Service Function Instance Route (SFIR), and the by this document: the Service Function Instance Route (SFIR), and the
Service Function Path Route (SFPR). As detailed in Section 3, the Service Function Path Route (SFPR). As detailed in Section 3, the
route type is indicated by a sub-field in the NLRI. route type is indicated by a sub-field in the NLRI.
o The SFIR is advertised by the node hosting the service function o The SFIR is advertised by the node hosting the service function
instance (i.e., the SFF). The SFIR describes a particular instance (i.e., the SFF). The SFIR describes a particular
instance of a particular Service Function (i.e., an SFI) and the instance of a particular Service Function (i.e., an SFI) and the
way to forward a packet to it through the underlay network, i.e., way to forward a packet to it through the underlay network, i.e.,
skipping to change at page 62, line 39 skipping to change at page 62, line 39
Function Chaining Service Function Types". Function Chaining Service Function Types".
Valid values are in the range 0 to 65535. Valid values are in the range 0 to 65535.
o Values 0 and 65535 are to be marked "Reserved, not to be o Values 0 and 65535 are to be marked "Reserved, not to be
allocated". allocated".
o Values 1 through 31 are to be assigned by "Standards Action" o Values 1 through 31 are to be assigned by "Standards Action"
[RFC8126] and are referred to as the Special Purpose SFT values. [RFC8126] and are referred to as the Special Purpose SFT values.
o Other values (32 through 65534) are to be assigned according to o Values 32 through 64495 are to be assigned according to the "First
the "First Come First Served" policy [RFC8126]. Come First Served" policy [RFC8126].
o Values 64496 through 65534 are for Private Use and are not to be
recorded by IANA.
This document should be given as a reference for this registry. This document should be given as a reference for this registry.
The new registry should track: The new registry should track:
o Value o Value
o Name o Name
o Reference Document or Contact o Reference Document or Contact
o Registration Date o Registration Date
The registry should initially be populated as follows: The registry should initially be populated as follows:
Value | Name | Reference | Date Value | Name | Reference | Date
------+-------------------------------+------------+--------------- ------+-------------------------------+------------+---------------
0 | Reserved, not to be allocated | [This.I-D] | Date-to-be-set 0 | Reserved, not to be allocated | [This.I-D] | Date-to-be-set
1 | Change Sequence | [This.I-D] | Date-to-be-set 1 | Change Sequence | [This.I-D] | Date-to-be-set
2-31 | Unassigned | | 2-31 | Unassigned | |
32 | Classifier | [This.I-D] | Date-to-be-set 32 | Classifier | [This.I-D] | Date-to-be-set
skipping to change at page 65, line 45 skipping to change at page 66, line 7
Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful
comments, and to Joel Halpern for discussions that improved this comments, and to Joel Halpern for discussions that improved this
document. Yuanlong Jiang provided a useful review and caught some document. Yuanlong Jiang provided a useful review and caught some
important issues. Stephane Litkowski did an exceptionally good and important issues. Stephane Litkowski did an exceptionally good and
detailed document shepherd review. detailed document shepherd review.
Andy Malis contributed text that formed the basis of Section 7.7. Andy Malis contributed text that formed the basis of Section 7.7.
Brian Carpenter and Martin Vigoureux provided useful reviews during Brian Carpenter and Martin Vigoureux provided useful reviews during
IETF last call. Thanks also to Sheng Jiang, Ravi Singh, Benjamin IETF last call. Thanks also to Sheng Jiang, Ravi Singh, Benjamin
Kaduk, Roman Danyliw, Adam Roach, and Barry Leiba for review Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana, and Barry Leiba for
comments. review comments. Ketan Talaulikar provided helpful discussion of the
SFT code point registry.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-rfc5575bis] [I-D.ietf-idr-rfc5575bis]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules", Bacher, "Dissemination of Flow Specification Rules",
draft-ietf-idr-rfc5575bis-25 (work in progress), May 2020. draft-ietf-idr-rfc5575bis-25 (work in progress), May 2020.
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15
(work in progress), December 4019. (work in progress), December 2019.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://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, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
 End of changes. 13 change blocks. 
13 lines changed or deleted 41 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/