draft-ietf-bess-nsh-bgp-control-plane-16.txt   draft-ietf-bess-nsh-bgp-control-plane-17.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: February 20, 2021 E. Rosen Expires: February 22, 2021 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
August 19, 2020 August 21, 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-16 draft-ietf-bess-nsh-bgp-control-plane-17
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 February 20, 2021. This Internet-Draft will expire on February 22, 2021.
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 2, line 35 skipping to change at page 2, line 35
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview of Service Function Chaining . . . . . . . . . . 6 2.1. Overview of Service Function Chaining . . . . . . . . . . 6
2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8
3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 12 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Service Function Instance Route (SFIR) . . . . . . . . . 13 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 13
3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 14 3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 14
3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 15 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 15
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 16 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 16
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 17 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 17
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 22 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 23
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 23 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Service Function Instance Routes . . . . . . . . . . . . 24 4.2. Service Function Instance Routes . . . . . . . . . . . . 24
4.3. Service Function Path Routes . . . . . . . . . . . . . . 24 4.3. Service Function Path Routes . . . . . . . . . . . . . . 25
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 26 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 27
4.5. Service Function Forwarder Operation . . . . . . . . . . 27 4.5. Service Function Forwarder Operation . . . . . . . . . . 27
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 28 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 28
5. Selection within Service Function Paths . . . . . . . . . . . 29 5. Selection within Service Function Paths . . . . . . . . . . . 30
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 31 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 32
6.1. Protocol Control of Looping, Jumping, and Branching . . . 32 6.1. Protocol Control of Looping, Jumping, and Branching . . . 32
6.2. Implications for Forwarding State . . . . . . . . . . . . 33 6.2. Implications for Forwarding State . . . . . . . . . . . . 33
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 33 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Correlating Service Function Path Instances . . . . . . . 33 7.1. Correlating Service Function Path Instances . . . . . . . 34
7.2. Considerations for Stateful Service Functions . . . . . . 34 7.2. Considerations for Stateful Service Functions . . . . . . 34
7.3. VPN Considerations and Private Service Functions . . . . 35 7.3. VPN Considerations and Private Service Functions . . . . 35
7.4. Flow Specification for SFC Classifiers . . . . . . . . . 35 7.4. Flow Specification for SFC Classifiers . . . . . . . . . 36
7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 37 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 38
7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 38 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 39
7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 38 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 39
7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 39 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 39
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 41 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 42
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 42 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 42
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 42 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 43
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 43 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 43
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 43 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 44
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 44 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 45
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 44 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 45
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 45 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 46
8.9. Examples of SFPs with Stateful Service Functions . . . . 46 8.9. Examples of SFPs with Stateful Service Functions . . . . 46
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 46 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 47
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 48 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 48
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 49 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 50
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 51 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 52
8.10. Examples Using IPv6 Addressing . . . . . . . . . . . . . 54 8.10. Examples Using IPv6 Addressing . . . . . . . . . . . . . 55
8.10.1. Example Explicit SFP With No Choices . . . . . . . . 56 8.10.1. Example Explicit SFP With No Choices . . . . . . . . 57
8.10.2. Example SFP With Choice of SFIs . . . . . . . . . . 57 8.10.2. Example SFP With Choice of SFIs . . . . . . . . . . 58
8.10.3. Example SFP With Open Choice of SFIs . . . . . . . . 57 8.10.3. Example SFP With Open Choice of SFIs . . . . . . . . 58
8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 58 8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 59
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 60
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 61 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 62
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 61 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 62
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 61 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 62
10.4. New SFP Association Type Registry . . . . . . . . . . . 62 10.4. New SFP Association Type Registry . . . . . . . . . . . 63
10.5. New Service Function Type Registry . . . . . . . . . . . 63 10.5. New Service Function Type Registry . . . . . . . . . . . 64
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 65 Community Sub-Types . . . . . . . . . . . . . . . . . . 66
10.7. New BGP Transitive Extended Community Type . . . . . . . 65 10.7. New BGP Transitive Extended Community Type . . . . . . . 66
10.8. New SFC Extended Community Sub-Types Registry . . . . . 65 10.8. New SFC Extended Community Sub-Types Registry . . . . . 66
10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 66 10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 67
10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 66 10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 67
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 66 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 67
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
13.1. Normative References . . . . . . . . . . . . . . . . . . 67 13.1. Normative References . . . . . . . . . . . . . . . . . . 68
13.2. Informative References . . . . . . . . . . . . . . . . . 69 13.2. Informative References . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
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
require a packet to pass through a series of Service Functions (SFs) require a packet to pass through a series of Service Functions (SFs)
(e.g., WAN and application accelerators, Deep Packet Inspection (DPI) (e.g., WAN and application accelerators, Deep Packet Inspection (DPI)
engines, firewalls, TCP optimizers, and server load balancers) in a engines, firewalls, TCP optimizers, and server load balancers) in a
specified order: this is termed "Service Function Chaining" (SFC). specified order: this is termed "Service Function Chaining" (SFC).
There are a number of issues associated with deploying and There are a number of issues associated with deploying and
maintaining service function chaining in production networks, which maintaining service function chaining in production networks, which
skipping to change at page 13, line 46 skipping to change at page 13, line 46
Figure 3 shows the Route Type specific NLRI of the SFIR. Figure 3 shows the Route Type specific NLRI of the SFIR.
+--------------------------------------------+ +--------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+--------------------------------------------+ +--------------------------------------------+
| Service Function Type (2 octets) | | Service Function Type (2 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 3: SFIR Route Type specific NLRI Figure 3: SFIR Route Type specific NLRI
Per [RFC4364] the RD field comprises a two byte Type field and a six [RFC4364] defines a Route Distinguisher (RD) to consist of a two byte
byte Value field. If two SFIRs are originated from different Type field and a six byte Value field and it defines RD types 0, 1,
administrative domains (within the same provier's operational and 2. In this specification, the RD (used for the SFIR) MUST be of
domain), they MUST have different RDs. In particular, SFIRs from type 0, 1, or 2.
different VPNs (for different service function overlay networks) MUST
have different RDs, and those RDs MUST be different from any non-VPN If two SFIRs are originated from different administrative domains
SFIRs. (within the same provier's operational domain), they MUST have
different RDs. In particular, SFIRs from different VPNs (for
different service function overlay networks) MUST have different RDs,
and those RDs MUST be different from any non-VPN SFIRs.
The Service Function Type identifies the functions/features a service The Service Function Type identifies the functions/features a service
function can offer, e.g., Classifier, firewall, load balancer. There function can offer, e.g., Classifier, firewall, load balancer. There
may be several SFIs that can perform a given Service Function. Each may be several SFIs that can perform a given Service Function. Each
node hosting an SFI MUST originate an SFIR for each type of SF that node hosting an SFI MUST originate an SFIR for each type of SF that
it hosts (as indicated by the SFT value), and it MAY advertise an it hosts (as indicated by the SFT value), and it MAY advertise an
SFIR for each instance of each type of SF. The minimal advertisement SFIR for each instance of each type of SF. The minimal advertisement
allows construction of valid SFPs and leaves the selection of SFIs to allows construction of valid SFPs and leaves the selection of SFIs to
the local SFF; the detailed advertisement may have scaling concerns, the local SFF; the detailed advertisement may have scaling concerns,
but allows a Controller that constructs an SFP to make an explicit but allows a Controller that constructs an SFP to make an explicit
skipping to change at page 16, line 30 skipping to change at page 16, line 42
Figure 6 shows the Route Type specific NLRI of the SFPR. Figure 6 shows the Route Type specific NLRI of the SFPR.
+-----------------------------------------------+ +-----------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
| Service Path Identifier (SPI) (3 octets) | | Service Path Identifier (SPI) (3 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 6: SFPR Route Type Specific NLRI Figure 6: SFPR Route Type Specific NLRI
Per [RFC4364] the RD field comprises a two byte Type field and a six [RFC4364] defines a Route Distinguisher (RD) to consist of a two byte
byte Value field. All SFPs MUST be associated with an RD. The Type field and a six byte Value field and it defines RD types 0, 1,
association of an SFP with an RD is determined by provisioning. If and 2. In this specification, the RD (used for the SFPR) MUST be of
two SFPRs are originated from different Controllers they MUST have type 0, 1, or 2.
different RDs. Additionally, SFPRs from different VPNs (i.e., in
different service function overlay networks) MUST have different RDs, All SFPs MUST be associated with an RD. The association of an SFP
and those RDs MUST be different from any non-VPN SFPRs. with an RD is determined by provisioning. If two SFPRs are
originated from different Controllers they MUST have different RDs.
Additionally, SFPRs from different VPNs (i.e., in different service
function overlay networks) MUST have different RDs, and those RDs
MUST be different from any non-VPN SFPRs.
The Service Path Identifier is defined in [RFC8300] and is the value The Service Path Identifier is defined in [RFC8300] and is the value
to be placed in the Service Path Identifier field of the NSH header to be placed in the Service Path Identifier field of the NSH header
of any packet sent on this Service Function Path. It is expected of any packet sent on this Service Function Path. It is expected
that one or more Controllers will originate these routes in order to that one or more Controllers will originate these routes in order to
configure a service function overlay network. configure a service function overlay network.
The SFP is described in a new BGP Path attribute, the SFP attribute. The SFP is described in a new BGP Path attribute, the SFP attribute.
Section 3.2.1 shows the format of that attribute. Section 3.2.1 shows the format of that attribute.
skipping to change at page 22, line 24 skipping to change at page 22, line 43
may be used at the hop. The SFIs are identified using the SFIR- may be used at the hop. The SFIs are identified using the SFIR-
RDs from the advertisements of the SFIs in the SFIRs. Note that RDs from the advertisements of the SFIs in the SFIRs. Note that
if the list contains one or more SFIR Pool Identifiers, then for if the list contains one or more SFIR Pool Identifiers, then for
each the SFIR-RD list is effectively expanded to include the SFIR- each the SFIR-RD list is effectively expanded to include the SFIR-
RD of each SFIR advertised with that SFIR Pool Identifier. An RD of each SFIR advertised with that SFIR Pool Identifier. An
SFIR-RD of value zero has special meaning as described in SFIR-RD of value zero has special meaning as described in
Section 5. Each entry in the list is eight octets long, and the Section 5. Each entry in the list is eight octets long, and the
number of entries in the list can be deduced from the value of the number of entries in the list can be deduced from the value of the
Length field. Length field.
Note that an SFIR-RD can be distinguished from an SFIR Pool Note that an SFIR-RD is of type 0, 1, or 2 (as described in
Identifier because they are both BGP Extended Communities but they Section 3.1. Thus the high order octet of an RD found in an SFIR-
have different extended community types. RD List always has a value of 0x00. However, the high order octet
of an SFIR Pool Identifier (an extended community with Type field
TBD6), will always have a non-zero value. This allows the node
processing the SFIR-RD List to distinguish between the two types
of list entry.
3.2.1.4. MPLS Swapping/Stacking Sub-TLV 3.2.1.4. MPLS Swapping/Stacking Sub-TLV
The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero length The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero length
sub-TLV that is OPTIONAL in the Hop TLV and is used when the data sub-TLV that is OPTIONAL in the Hop TLV and is used when the data
representation is MPLS (see Section 7.5). When present it indicates representation is MPLS (see Section 7.5). When present it indicates
to the Classifier imposing an MPLS label stack that the current hop to the Classifier imposing an MPLS label stack that the current hop
is to use an {SFC Context Label, SF label} rather than an {SPI, SF} is to use an {SFC Context Label, SF label} rather than an {SPI, SF}
label pair. See Section 7.6 for more details. label pair. See Section 7.6 for more details.
skipping to change at page 67, line 34 skipping to change at page 68, line 34
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, Med Boucadair, Ravi IETF last call. Thanks also to Sheng Jiang, Med Boucadair, Ravi
Singh, Benjamin Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana, Singh, Benjamin Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana,
Barry Leiba, and Murray Kucherawy for review comments. Ketan Barry Leiba, and Murray Kucherawy for review comments. Ketan
Talaulikar provided helpful discussion of the SFT code point Talaulikar provided helpful discussion of the SFT code point
registry, and Ron Bonica kept us honest on the difference between an registry. Ron Bonica kept us honest on the difference between an RD
RD and RT. and RT; Benjamin Kaduk kept us on message about the differnce between
an RD and an extended community.
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-26 (work in progress), August draft-ietf-idr-rfc5575bis-26 (work in progress), August
2020. 2020.
 End of changes. 19 change blocks. 
68 lines changed or deleted 81 lines changed or added

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