draft-ietf-mpls-rfc3107bis-01.txt   draft-ietf-mpls-rfc3107bis-02.txt 
Internet Engineering Task Force E. Rosen, Ed. Internet Engineering Task Force E. Rosen
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Obsoletes: 3107 (if approved) March 13, 2017 Obsoletes: 3107 (if approved) May 11, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: September 14, 2017 Expires: November 12, 2017
Using BGP to Bind MPLS Labels to Address Prefixes Using BGP to Bind MPLS Labels to Address Prefixes
draft-ietf-mpls-rfc3107bis-01 draft-ietf-mpls-rfc3107bis-02
Abstract Abstract
This document specifies a set of procedures for using BGP to This document specifies a set of procedures for using BGP to
advertise that a specified router has bound a specified MPLS label advertise that a specified router has bound a specified MPLS label
(or a specified sequence of MPLS labels, organized as a contiguous (or a specified sequence of MPLS labels, organized as a contiguous
part of a label stack) to a specified address prefix. This can be part of a label stack) to a specified address prefix. This can be
done by sending a BGP UPDATE message whose Network Layer Reachability done by sending a BGP UPDATE message whose Network Layer Reachability
Information field contains both the prefix and the MPLS label(s), and Information field contains both the prefix and the MPLS label(s), and
whose Next Hop field identifies the node at which said prefix is whose Next Hop field identifies the node at which said prefix is
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 14, 2017. This Internet-Draft will expire on November 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 11 Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Changing the Label that is Bound to a Prefix . . . . . . 12 2.5. Changing the Label that is Bound to a Prefix . . . . . . 12
3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes . . . 13 3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes . . . 13
3.1. Comparability of Routes . . . . . . . . . . . . . . . . . 13 3.1. Comparability of Routes . . . . . . . . . . . . . . . . . 13
3.2. Modification of Label(s) Field When Propagating . . . . . 14 3.2. Modification of Label(s) Field When Propagating . . . . . 14
3.2.1. When the Next Hop Field is Unchanged . . . . . . . . 14 3.2.1. When the Next Hop Field is Unchanged . . . . . . . . 14
3.2.2. When the Next Hop Field is Changed . . . . . . . . . 14 3.2.2. When the Next Hop Field is Changed . . . . . . . . . 14
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Relationship Between SAFI-4 and SAFI-1 Routes . . . . . . . . 17 5. Relationship Between SAFI-4 and SAFI-1 Routes . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[RFC3107] specifies encodings and procedures for using BGP to [RFC3107] specifies encodings and procedures for using BGP to
indicate that a particular router has bound either a single MPLS indicate that a particular router has bound either a single MPLS
label or a sequence of MPLS labels (organized as a contiguous part of label or a sequence of MPLS labels (organized as a contiguous part of
an MPLS label stack) ([RFC3031], [RFC3032]) to a particular address an MPLS label stack) ([RFC3031], [RFC3032]) to a particular address
skipping to change at page 4, line 26 skipping to change at page 4, line 26
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Using BGP to Bind an Address Prefix to One or More MPLS Labels 2. Using BGP to Bind an Address Prefix to One or More MPLS Labels
BGP may be used to advertise that a particular node, call it N, has BGP may be used to advertise that a particular node, call it N, has
bound a particular MPLS label, or a particular sequence of MPLS bound a particular MPLS label, or a particular sequence of MPLS
labels (organized as a contiguous part of an MPLS label stack), to a labels (organized as a contiguous part of an MPLS label stack), to a
particular address prefix. This is done by sending a Multiprotocol particular address prefix. This is done by sending a Multiprotocol
BGP UPDATE message, i.e., an UPDATE message with an MP_REACH_NLRI BGP UPDATE message, i.e., an UPDATE message with an MP_REACH_NLRI
attribute ([RFC4760]. The "Network Address of Next Hop" field of attribute ([RFC4760]). The "Network Address of Next Hop" field of
that attribute contains an IP address of node N. The label(s) and that attribute contains an IP address of node N. The label(s) and
the prefix are encoded in the NLRI field of the MP_REACH_NLRI. The the prefix are encoded in the NLRI field of the MP_REACH_NLRI. The
encoding of the NLRI field is specified in Sections 2.2 and 2.3. encoding of the NLRI field is specified in Sections 2.2 and 2.3.
If the prefix is an IPv4 address prefix or a VPN-IPv4 ([RFC4364]) If the prefix is an IPv4 address prefix or a VPN-IPv4 ([RFC4364])
address prefix, the Address Family Identifier (AFI) of the address prefix, the Address Family Identifier (AFI) of the
MP_REACH_NLRI attribute is set to 1. If the prefix is an IPv6 MP_REACH_NLRI attribute is set to 1. If the prefix is an IPv6
address prefix or a VPN-IPv6 prefix ([RFC4659], the AFI is set to 2. address prefix or a VPN-IPv6 prefix ([RFC4659]), the AFI is set to 2.
If the prefix is an IPv4 address prefix or an IPv6 address prefix, If the prefix is an IPv4 address prefix or an IPv6 address prefix,
the Subsequent Address Family Identifier (SAFI) field is set to 4. the Subsequent Address Family Identifier (SAFI) field is set to 4.
If the prefix is a VPN-IPv4 address prefix or a VPN-IPv6 address If the prefix is a VPN-IPv4 address prefix or a VPN-IPv6 address
prefix, the SAFI is set to 128. prefix, the SAFI is set to 128.
The use of SAFI 4 or SAFI 128 when the AFI is other than 1 or 2 is The use of SAFI 4 or SAFI 128 when the AFI is other than 1 or 2 is
outside the scope of this document. outside the scope of this document.
This document does not specify the format of the "Network Address of This document does not specify the format of the "Network Address of
skipping to change at page 5, line 12 skipping to change at page 5, line 12
There are a variety of applications that make use of alternative There are a variety of applications that make use of alternative
methods of using BGP to advertise MPLS label bindings. See, e.g., methods of using BGP to advertise MPLS label bindings. See, e.g.,
[RFC7432], [RFC6514], or [TUNNEL-ENCAPS]. The method described in [RFC7432], [RFC6514], or [TUNNEL-ENCAPS]. The method described in
the current document is not claimed to be the only way of using BGP the current document is not claimed to be the only way of using BGP
to advertise MPLS label bindings. Discussion of which method to use to advertise MPLS label bindings. Discussion of which method to use
for which application is outside the scope of the current document. for which application is outside the scope of the current document.
In the remainder of this document, we will use the term "SAFI-x In the remainder of this document, we will use the term "SAFI-x
UPDATE" to refer to a BGP UPDATE message containing an MP_REACH_NLRI UPDATE" to refer to a BGP UPDATE message containing an MP_REACH_NLRI
attribute or an MP_UNREACH_NLRI attribute ([RFC4760] whose SAFI field attribute or an MP_UNREACH_NLRI attribute ([RFC4760]) whose SAFI
contains the value x. field contains the value x.
This document defines a BGP Optional Capabilities parameter This document defines a BGP Optional Capabilities parameter
([RFC5492]) known as the "Multiple Labels Capability". ([RFC5492]) known as the "Multiple Labels Capability".
o Unless this Capability is sent on a given BGP session by both of o Unless this Capability is sent on a given BGP session by both of
that session's BGP speakers, a SAFI-4 or SAFI-128 UPDATE message that session's BGP speakers, a SAFI-4 or SAFI-128 UPDATE message
sent on that session from either speaker MUST bind a prefix to sent on that session from either speaker MUST bind a prefix to
only a single label, and MUST use the encoding of Section 2.2. only a single label, and MUST use the encoding of Section 2.2.
o If this Capability is sent by both BGP speakers on a given o If this Capability is sent by both BGP speakers on a given
skipping to change at page 6, line 21 skipping to change at page 6, line 21
session any UPDATE message that binds more than one MPLS label to any session any UPDATE message that binds more than one MPLS label to any
given prefix. Further, when advertising the binding of a single given prefix. Further, when advertising the binding of a single
label to a prefix, the BGP speaker MUST use the encoding specified in label to a prefix, the BGP speaker MUST use the encoding specified in
Section 2.2. Section 2.2.
The value field of the Multiple Labels Capability (shown in Figure 1) The value field of the Multiple Labels Capability (shown in Figure 1)
consists of one or more triples, where each triple consists of four consists of one or more triples, where each triple consists of four
octets. The first two octets of a triple specify an AFI value, the octets. The first two octets of a triple specify an AFI value, the
third octet specifies a SAFI value, and the fourth specifies a Count. third octet specifies a SAFI value, and the fourth specifies a Count.
If one of the triples is <AFI,SAFI,Count>, the Count is the maximum If one of the triples is <AFI,SAFI,Count>, the Count is the maximum
number of labels that the BGP speaker can process in a received number of labels that the BGP speaker sending the Capability can
UPDATE of the specified AFI/SAFI. process in a received UPDATE of the specified AFI/SAFI. If the count
is 255, then no limit has been placed on the number of labels that
can be processed in a received UPDATE of the specified AFI/SAFI.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | SAFI | Count ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AFI | SAFI | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Value Field of Multiple Labels Capability
If the Capability contains more than one triple with a given AFI/ If the Capability contains more than one triple with a given AFI/
SAFI, all but the first MUST be ignored. SAFI, all but the first MUST be ignored.
Any triple of the form <AFI=x,SAFI=y,Count=0> MUST be ignored. Any triple of the form <AFI=x,SAFI=y,Count=0> MUST be ignored.
If the Capability contains the triple <AFI=x,SAFI=y,Count=255>, then
no limit has been placed on the number of labels that can be
advertised in UPDATEs of the corresponding AFI/SAFI.
A Multiple Labels Capability whose length is not a multiple of four A Multiple Labels Capability whose length is not a multiple of four
MUST be considered to be malformed. MUST be considered to be malformed.
[RFC4724] ("Graceful Restart Mechanism for BGP") describes a [RFC4724] ("Graceful Restart Mechanism for BGP") describes a
procedure that allows routes learned over a given BGP session to be procedure that allows routes learned over a given BGP session to be
maintained when the session fails and then restarts. This procedure maintained when the session fails and then restarts. This procedure
requires the entire RIB to be transmitted when the session restarts. requires the entire RIB to be transmitted when the session restarts.
If the Multiple Labels Capability for a given AFI/SAFI had been If the Multiple Labels Capability for a given AFI/SAFI had been
exchanged on the failed session, but is not exchanged on the exchanged on the failed session, but is not exchanged on the
restarted session, then any prefixes advertised in that AFI/SAFI with restarted session, then any prefixes advertised in that AFI/SAFI with
multiple labels MUST be explicitly withdrawn. Similarly, if the multiple labels MUST be explicitly withdrawn. Similarly, if the
maximum label count, specified in the Capability for a given AFI/SAFI maximum label count, specified in the Capability for a given AFI/SAFI
is reduced, an prefixes advertised with more labels than are valid is reduced, any prefixes advertised with more labels than are valid
for the current session MUST be explicitly withdrawn. for the current session MUST be explicitly withdrawn.
[Enhanced-GR] ("Accelerated Routing Convergence for BGP Graceful [Enhanced-GR] ("Accelerated Routing Convergence for BGP Graceful
Restart") describes another procedure that allows the routes learned Restart") describes another procedure that allows the routes learned
over a given BGP session to be maintained when the session fails and over a given BGP session to be maintained when the session fails and
then restarts. These procedures MUST NOT be applied if either of the then restarts. These procedures MUST NOT be applied if either of the
following conditions hold: following conditions hold:
o The Multiple Labels Capability for a given AFI/SAFI had been o The Multiple Labels Capability for a given AFI/SAFI had been
exchanged prior to the restart, but has not been exchanged on the exchanged prior to the restart, but has not been exchanged on the
restarted session. restarted session.
o The Multiple Labels Capability for a given AFI/SAFI had been o The Multiple Labels Capability for a given AFI/SAFI had been
exchanged with a given Count prior to the restart, but has been exchanged with a given Count prior to the restart, but has been
exchanged with a smaller count on the restarted session. exchanged with a smaller count on the restarted session.
If either of these conditions holds, the complete set of routes for If either of these conditions hold, the complete set of routes for of
of the given AFI/SAFI MUST be exchanged. the given AFI/SAFI MUST be exchanged.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | SAFI | Count ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AFI | SAFI | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Value Field of Multiple Labels Capability
If a BGP OPEN message contains multiple copies of the Multiple Labels If a BGP OPEN message contains multiple copies of the Multiple Labels
Capability, only the first copy is significant; subsequent copies Capability, only the first copy is significant; subsequent copies
MUST BE ignored. MUST be ignored.
If a BGP speaker has sent the Multiple Labels Capability in its BGP If a BGP speaker has sent the Multiple Labels Capability in its BGP
OPEN message for a particular BGP session, and has also received the OPEN message for a particular BGP session, and has also received the
Multiple Labels Capability in its peer's BGP OPEN message for that Multiple Labels Capability in its peer's BGP OPEN message for that
session, and if both Capabilities specify AFI/SAFI x/y, then: session, and if both Capabilities specify AFI/SAFI x/y, then:
when using an UPDATE of AFI x and SAFI y to advertise the binding when using an UPDATE of AFI x and SAFI y to advertise the binding
of a label or sequence of labels to a given prefix, the BGP of a label or sequence of labels to a given prefix, the BGP
speaker MUST use the encoding of Section 2.3. This encoding MUST speaker MUST use the encoding of Section 2.3. This encoding MUST
be used even if only one label is being bound to a given prefix. be used even if only one label is being bound to a given prefix.
skipping to change at page 8, line 4 skipping to change at page 7, line 49
If both BGP speakers of a given BGP session have sent the Multiple If both BGP speakers of a given BGP session have sent the Multiple
Labels Capability, but AFI/SAFI x/y has not been specified in both Labels Capability, but AFI/SAFI x/y has not been specified in both
Capabilities, then UPDATES of AFI/SAFI x/y on that session MUST use Capabilities, then UPDATES of AFI/SAFI x/y on that session MUST use
the encoding of Section 2.2, and such UPDATEs can only bind one label the encoding of Section 2.2, and such UPDATEs can only bind one label
to a prefix. to a prefix.
A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a
given prefix than its peer is capable of receiving, as specified in given prefix than its peer is capable of receiving, as specified in
the Multiple Labels Capability sent by that peer. If a BGP speaker the Multiple Labels Capability sent by that peer. If a BGP speaker
receives an UPDATE that binds more labels to a given prefix than the receives an UPDATE that binds more labels to a given prefix than the
number of prefixes the BGP speaker is prepared to receive (as number of labels the BGP speaker is prepared to receive (as announced
announced in its Multiple Labels Capability), the BGP speaker MUST in its Multiple Labels Capability), the BGP speaker MUST apply the
apply the "treat-as-withdraw" strategy of [RFC7606] to that UPDATE. "treat-as-withdraw" strategy of [RFC7606] to that UPDATE.
Notwithstanding the number of labels that a BGP speaker has claimed Notwithstanding the number of labels that a BGP speaker has claimed
to be able to receive, its peer MUST NOT attempt to send more labels to be able to receive, its peer MUST NOT attempt to send more labels
than can be properly encoded in the NLRI field of the MP_REACH_NLRI than can be properly encoded in the NLRI field of the MP_REACH_NLRI
attribute. Please note that there is only a limited amount of space attribute. Please note that there is only a limited amount of space
in the NLRI field for labels: in the NLRI field for labels:
o per [RFC4760] the size of this field is limited to 255 bits (not o per [RFC4760] the size of this field is limited to 255 bits (not
255 octets), including the number of bits in the prefix; 255 octets), including the number of bits in the prefix;
skipping to change at page 9, line 7 skipping to change at page 9, line 5
in label field) plus 3 (number of bits in Rsrv field) plus 1 in label field) plus 3 (number of bits in Rsrv field) plus 1
(number of bits in S field) plus the length in bits of the prefix. (number of bits in S field) plus the length in bits of the prefix.
In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix
length will be 32 bits or less. In an MP_REACH_NLRI attribute length will be 32 bits or less. In an MP_REACH_NLRI attribute
whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less. whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less.
In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will
be 96 bits or less if the AFI is 1, and will be 192 bits or less be 96 bits or less if the AFI is 1, and will be 192 bits or less
if the AFI is 2. if the AFI is 2.
As specified in [RFC4760], actual length of the NLRI field will be As specified in [RFC4760], the actual length of the NLRI field
the number of bits specified in the length field, rounded up to will be the number of bits specified in the length field, rounded
the nearest integral number of octets. up to the nearest integral number of octets.
- Label: - Label:
The Label field is a 20-bit field, containing an MPLS label value The Label field is a 20-bit field, containing an MPLS label value
(see [RFC3032]). (see [RFC3032]).
- Rsrv: - Rsrv:
This 3-bit field SHOULD be set to zero on transmission, and MUST This 3-bit field SHOULD be set to zero on transmission, and MUST
be ignored on reception. be ignored on reception.
skipping to change at page 10, line 37 skipping to change at page 10, line 35
Note that for each label, the length is increased by 24 bits (20 Note that for each label, the length is increased by 24 bits (20
bits in label field plus 3 bits in Rsrv field plus 1 S bit). bits in label field plus 3 bits in Rsrv field plus 1 S bit).
In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix
length will be 32 bits or less. In an MP_REACH_NLRI attribute length will be 32 bits or less. In an MP_REACH_NLRI attribute
whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less. whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less.
In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will
be 96 bits or less if the AFI is 1, and will be 192 bits or less be 96 bits or less if the AFI is 1, and will be 192 bits or less
if the AFI is 2. if the AFI is 2.
As specified in [RFC4760], actual length of the NLRI field will be As specified in [RFC4760], the actual length of the NLRI field
the number of bits specified in the length field, rounded up to will be the number of bits specified in the length field, rounded
the nearest integral number of octets. up to the nearest integral number of octets.
- Label: - Label:
The Label field is a 20-bit field, containing an MPLS label value The Label field is a 20-bit field, containing an MPLS label value
([RFC3032]). ([RFC3032]).
- Rsrv: - Rsrv:
This 3-bit field SHOULD be set to zero on transmission, and MUST This 3-bit field SHOULD be set to zero on transmission, and MUST
be ignored on reception. be ignored on reception.
skipping to change at page 11, line 52 skipping to change at page 11, line 52
Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon transmission, the Compatibility field SHOULD be set to 0x800000.
Upon reception, the value of the Compatibility field MUST be ignored. Upon reception, the value of the Compatibility field MUST be ignored.
This encoding is used for explicitly withdrawing the binding, on a This encoding is used for explicitly withdrawing the binding, on a
given BGP session, between the specified prefix and whatever label or given BGP session, between the specified prefix and whatever label or
sequence of labels had previously been bound by the procedures of sequence of labels had previously been bound by the procedures of
this document to that prefix on the given session. This encoding is this document to that prefix on the given session. This encoding is
used whether or not the Multiple Labels Capability has been sent or used whether or not the Multiple Labels Capability has been sent or
received on the session. Note that label/prefix bindings that were received on the session. Note that label/prefix bindings that were
not advertised on the given session cannot be withdrawn by this not advertised on the given session cannot be withdrawn by this
method. method. (However, if the bindings were advertised on a previous
session with the same peer, and the current session is the result of
a "graceful restart" ([RFC4724]) of the previous session, then this
withdrawal method may be used.)
When using an MP_UNREACH_NLRI attribute to withdraw a route whose When using an MP_UNREACH_NLRI attribute to withdraw a route whose
NLRI was previously specified in an MP_REACH_NLRI attribute, the NLRI was previously specified in an MP_REACH_NLRI attribute, the
lengths and values of the respective prefixes must match, and the lengths and values of the respective prefixes must match, and the
respective AFI/SAFIs must match. If the procedures of [RFC7911] are respective AFI/SAFIs must match. If the procedures of [RFC7911] are
being used, the respective values of the "path identifier" fields being used, the respective values of the "path identifier" fields
must match as well. Note that the prefix length is not the same as must match as well. Note that the prefix length is not the same as
the NLRI length; to determine the prefix length of a prefix in an the NLRI length; to determine the prefix length of a prefix in an
MP_UNREACH_NLRI, the length of the Compatibility field must be MP_UNREACH_NLRI, the length of the Compatibility field must be
subtracted from the length of the NLRI. subtracted from the length of the NLRI.
skipping to change at page 12, line 31 skipping to change at page 12, line 34
Compatibility field. However, the functionality that required the Compatibility field. However, the functionality that required the
presence of a particular label value (or sequence of label values) presence of a particular label value (or sequence of label values)
was never implemented, and that functionality is not present in the was never implemented, and that functionality is not present in the
current document. Hence the value of this field is of no current document. Hence the value of this field is of no
significance; there is never any reason for this field to contain a significance; there is never any reason for this field to contain a
label value or a sequence of label values. label value or a sequence of label values.
[RFC3107] also allowed one to withdraw a binding without specifying [RFC3107] also allowed one to withdraw a binding without specifying
the label explicitly, by setting the Compatibility field to 0x800000. the label explicitly, by setting the Compatibility field to 0x800000.
However, some implementations set it to 0x000000. In order to ensure However, some implementations set it to 0x000000. In order to ensure
backwards compatibility, this document RECOMMENDS that the backwards compatibility, it is RECOMMENDED by this document that the
Compatibility field be set to 0x800000, but REQUIRES that it be Compatibility field be set to 0x800000, but it is REQUIRED that it be
ignored upon reception. ignored upon reception.
2.5. Changing the Label that is Bound to a Prefix 2.5. Changing the Label that is Bound to a Prefix
Suppose a BGP speaker, S1, has received on a given BGP session, a Suppose a BGP speaker, S1, has received on a given BGP session, a
SAFI-4 or SAFI-128 UPDATE, U1, that specifies label (or sequence of SAFI-4 or SAFI-128 UPDATE, U1, that specifies label (or sequence of
labels) L1, prefix P, and next hop N1. As specified above, this labels) L1, prefix P, and next hop N1. As specified above, this
indicates that label (or sequence of labels) L1 is bound to prefix P indicates that label (or sequence of labels) L1 is bound to prefix P
at node N1. Suppose that S1 now receives, on the same session, an at node N1. Suppose that S1 now receives, on the same session, an
UPDATE, U2, of the same AFI/SAFI, that specifies label (or sequence UPDATE, U2, of the same AFI/SAFI, that specifies label (or sequence
skipping to change at page 13, line 13 skipping to change at page 13, line 16
Identifier I1, and that UPDATE U2 has Path Identifier I2. Identifier I1, and that UPDATE U2 has Path Identifier I2.
* If I1 is the same as I2, UPDATE U2 MUST be interpreted as * If I1 is the same as I2, UPDATE U2 MUST be interpreted as
meaning that L2 is now bound to P at N1, and that L1 is no meaning that L2 is now bound to P at N1, and that L1 is no
longer bound to P at N1. UPDATE U1 is implicitly withdrawn. longer bound to P at N1. UPDATE U1 is implicitly withdrawn.
* If I1 is not the same as I2, U2 MUST be interpreted as meaning * If I1 is not the same as I2, U2 MUST be interpreted as meaning
that L2 is now bound to P at N1, but MUST NOT be interpreted as that L2 is now bound to P at N1, but MUST NOT be interpreted as
meaning that L1 is no longer bound to P at N1. Under certain meaning that L1 is no longer bound to P at N1. Under certain
conditions (specification of which is outside the scope of this conditions (specification of which is outside the scope of this
document), S1 may choose to load balance traffic between the document), S1 may choose to load-balance traffic between the
path represented by U1 and the path represented by U2. To send path represented by U1 and the path represented by U2. To send
traffic on the path represented by U1, S1 uses the label(s) traffic on the path represented by U1, S1 uses the label(s)
advertised in U1; to send traffic on the path represented by advertised in U1; to send traffic on the path represented by
U2, S1 uses the label(s) advertised in U2. (Although these two U2, S1 uses the label(s) advertised in U2. (Although these two
paths have the same next hop, one must suppose that they paths have the same next hop, one must suppose that they
diverge further downstream.) diverge further downstream.)
Suppose a BGP speaker, S1, has received, on a given BGP session, a Suppose a BGP speaker, S1, has received, on a given BGP session, a
SAFI-4 or SAFI-128 UPDATE that specifies label L1, prefix P, and next SAFI-4 or SAFI-128 UPDATE that specifies label L1, prefix P, and next
hop N1. Suppose that S1 now receives, on a different BGP session, an hop N1. Suppose that S1 now receives, on a different BGP session, an
UPDATE, of the same AFI/SAFI, that specifies label L2, prefix P, and UPDATE, of the same AFI/SAFI, that specifies label L2, prefix P, and
the same next hop, N1. BGP speaker S1 SHOULD treat this as the same next hop, N1. BGP speaker S1 SHOULD treat this as
indicating that N1 has at least two paths to P, and S MAY use this indicating that N1 has at least two paths to P, and S1 MAY use this
fact to do load-balancing of any traffic that it has to send to P. fact to do load-balancing of any traffic that it has to send to P.
Note that this section discusses only the case where two UPDATEs have Note that this section discusses only the case where two UPDATEs have
the same next hop. Procedures for the case where two UPDATEs have the same next hop. Procedures for the case where two UPDATEs have
different next hops are adequately described in [RFC4271]. different next hops are adequately described in [RFC4271].
3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes 3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes
3.1. Comparability of Routes 3.1. Comparability of Routes
skipping to change at page 14, line 5 skipping to change at page 14, line 7
used on that session, and the NLRIs of the two updates have used on that session, and the NLRIs of the two updates have
different path identifiers. different path identifiers.
These two routes MUST be considered to be comparable, even if they These two routes MUST be considered to be comparable, even if they
specify different labels. Thus the BGP bestpath selection procedures specify different labels. Thus the BGP bestpath selection procedures
(Section 9.1 of [RFC4271]) are applied to select one of them as the (Section 9.1 of [RFC4271]) are applied to select one of them as the
better path. If the procedures of [RFC7911] are not being used on a better path. If the procedures of [RFC7911] are not being used on a
particular BGP session, only the best path is propagated on that particular BGP session, only the best path is propagated on that
session. If the procedures of [RFC7911] are being used on a session. If the procedures of [RFC7911] are being used on a
particular BGP session, then both paths may be propagated on that particular BGP session, then both paths may be propagated on that
session, though with different path identifiers.. session, though with different path identifiers.
The same applies to SAFI-128 routes. The same applies to SAFI-128 routes.
3.2. Modification of Label(s) Field When Propagating 3.2. Modification of Label(s) Field When Propagating
3.2.1. When the Next Hop Field is Unchanged 3.2.1. When the Next Hop Field is Unchanged
When a SAFI-4 or SAFI-128 route is propagated, if the "Network When a SAFI-4 or SAFI-128 route is propagated, if the "Network
Address of Next Hop" field is left unchanged, the label field(s) MUST Address of Next Hop" field is left unchanged, the label field(s) MUST
also be left unchanged. also be left unchanged.
Note that a given route MUST NOT be propagated to a given peer if the Note that a given route MUST NOT be propagated to a given peer if the
route's NLRI has multiple labels, but the peer can only handle a route's NLRI has multiple labels, but the "Multiple Labels"
single label in the NLRI. Similarly, a given route SHOULD NOT be Capability was not negotiated with the peer. Similarly, a given
propagated to a given peer if the route's NLRI has more labels than route MUST NOT be propagated to a given peer if the route's NLRI has
the peer has announced (through its "Multiple Labels" Capability) more labels than the peer has announced (through its "Multiple
that it can handle. In either case, if a previous route with the Labels" Capability) that it can handle. In either case, if a
same AFI, SAFI, and prefix (but with fewer labels) has already been previous route with the same AFI, SAFI, and prefix (but with fewer
propagated to the peer, that route MUST be withdrawn from that peer, labels) has already been propagated to the peer, that route MUST be
using the procedure of Figure 4. withdrawn from that peer, using the procedure of Section 2.4.
3.2.2. When the Next Hop Field is Changed 3.2.2. When the Next Hop Field is Changed
If the "Network Address of Next Hop" field is changed before a SAFI-4 If the "Network Address of Next Hop" field is changed before a SAFI-4
or SAFI-128 route is propagated, the label field(s) of the propagated or SAFI-128 route is propagated, the label field(s) of the propagated
route MUST contain the label(s) that that is (are) bound to the route MUST contain the label(s) that that is (are) bound to the
prefix at the new next hop. prefix at the new next hop.
Suppose BGP speaker S1 has received an UPDATE that binds a particular Suppose BGP speaker S1 has received an UPDATE that binds a particular
sequence of one or more labels to a particular prefix. If S1 chooses sequence of one or more labels to a particular prefix. If S1 chooses
skipping to change at page 15, line 7 skipping to change at page 15, line 10
o A sequence of multiple labels may be replaced by a sequence of o A sequence of multiple labels may be replaced by a sequence of
multiple labels; the number of labels may be left the same, or may multiple labels; the number of labels may be left the same, or may
be changed. be changed.
Of course, when deciding whether to propagate, to a given BGP peer, Of course, when deciding whether to propagate, to a given BGP peer,
an UPDATE binding a sequence of more than one label, a BGP speaker an UPDATE binding a sequence of more than one label, a BGP speaker
must attend to the information provided by the Multiple Labels must attend to the information provided by the Multiple Labels
Capability (see Section 2.1). A BGP speaker MUST NOT send multiple Capability (see Section 2.1). A BGP speaker MUST NOT send multiple
labels to a peer with which it has not exchanged the "Multiple labels to a peer with which it has not exchanged the "Multiple
Labels" Capability, and SHOULD NOT send more labels to a given peer Labels" Capability, and MUST NOT send more labels to a given peer
than the peer has announced (via the "Multiple Labels" Capability) than the peer has announced (via the "Multiple Labels" Capability)
than it can handle. than it can handle.
It is possible that a BGP speaker's local policy will tell it to It is possible that a BGP speaker's local policy will tell it to
encode N labels in a given route's NLRI before propagating the route, encode N labels in a given route's NLRI before propagating the route,
but that one of the BGP speaker's peers cannot handle N labels in the but that one of the BGP speaker's peers cannot handle N labels in the
NLRI. In this case, the BGP speaker has two choices: NLRI. In this case, the BGP speaker has two choices:
o It can propagate the route to the given peer with fewer than N o It can propagate the route to the given peer with fewer than N
labels. However, whether this makes sense, and if so, how to labels. However, whether this makes sense, and if so, how to
choose the labels, is also a matter of local policy choose the labels, is also a matter of local policy.
o It can decide not to propagate the route to the given peer. In o It can decide not to propagate the route to the given peer. In
that case, if a previous route with the same AFI, SAFI, and prefix that case, if a previous route with the same AFI, SAFI, and prefix
(but with fewer labels) has already been propagated to that peer, (but with fewer labels) has already been propagated to that peer,
that route MUST be withdrawn from that peer, using the procedure that route MUST be withdrawn from that peer, using the procedure
of Figure 4. of Section 2.4.
4. Data Plane 4. Data Plane
In the following, we will use the phrase "node S tunnels packet P to In the following, we will use the phrase "node S tunnels packet P to
node N", where packet P is an MPLS packet. By this phrase, we mean node N", where packet P is an MPLS packet. By this phrase, we mean
that node S encapsulates packet P and causes packet P to be delivered that node S encapsulates packet P and causes packet P to be delivered
to node N, in such a way that P's label stack before encapsulation to node N, in such a way that P's label stack before encapsulation
will be seen unchanged by N, but will not be seen by the nodes (if will be seen unchanged by N, but will not be seen by the nodes (if
any) between S and N. any) between S and N.
If the tunnel is a Label Switched Path (LSP), encapsulating the If the tunnel is a Label Switched Path (LSP), encapsulating the
packet may be as simple as pushing on another MPLS label. If node N packet may be as simple as pushing on another MPLS label. If node N
is a layer 2 adjacency of node S, S a layer 2 encapsulation may be is a layer 2 adjacency of node S, a layer 2 encapsulation may be all
all that is needed. Other sorts of tunnels (e.g., IP tunnels, GRE that is needed. Other sorts of tunnels (e.g., IP tunnels, GRE
tunnels, UDP tunnels) may also be used, depending upon the particular tunnels, UDP tunnels) may also be used, depending upon the particular
deployment scenario. deployment scenario.
Suppose BGP speaker S1 receives a SAFI-4 or SAFI-128 BGP UPDATE with Suppose BGP speaker S1 receives a SAFI-4 or SAFI-128 BGP UPDATE with
an MP_REACH_NLRI specifying label L1, prefix P, and next hop N1, and an MP_REACH_NLRI specifying label L1, prefix P, and next hop N1, and
suppose S1 installs this route as its (or one of its) bestpath(s) suppose S1 installs this route as its (or one of its) bestpath(s)
towards P. And suppose S1 propagates this route after changing the towards P. And suppose S1 propagates this route after changing the
next hop to itself and changing the label to L2. Suppose further next hop to itself and changing the label to L2. Suppose further
that S1 receives an MPLS data packet, and in the process of that S1 receives an MPLS data packet, and in the process of
forwarding that MPLS data packet, S1 sees label L2 rise to the top of forwarding that MPLS data packet, S1 sees label L2 rise to the top of
skipping to change at page 17, line 43 skipping to change at page 17, line 45
match" for D from among the routes that are being used to forward IP match" for D from among the routes that are being used to forward IP
packets. And suppose the packet is being forwarded according to a packets. And suppose the packet is being forwarded according to a
SAFI-4 route whose prefix is P, whose next hop is N1, and whose SAFI-4 route whose prefix is P, whose next hop is N1, and whose
sequence of labels is L1. To forward the packet according to this sequence of labels is L1. To forward the packet according to this
route, S1 must create a label stack for the packet, push on the route, S1 must create a label stack for the packet, push on the
sequence of labels L1, and then tunnel the packet to N1. sequence of labels L1, and then tunnel the packet to N1.
5. Relationship Between SAFI-4 and SAFI-1 Routes 5. Relationship Between SAFI-4 and SAFI-1 Routes
It is possible that a BGP speaker will receive both a SAFI-1 route It is possible that a BGP speaker will receive both a SAFI-1 route
for prefix P and a SAFI-4 route for prefix P. The significance of for prefix P and a SAFI-4 route for prefix P. Different
this is a matter of local policy. implementations treat this situation in different ways.
For example, some implementations may regard SAFI-1 routes and SAFI-4 For example, some implementations may regard SAFI-1 routes and SAFI-4
routes as completely independent, and may treat them in a "ships in routes as completely independent, and may treat them in a "ships in
the night" fashion. In this case, bestpath selection for the two the night" fashion. In this case, bestpath selection for the two
SAFIs is independent, and there will be a best SAFI-1 route to P as SAFIs is independent, and there will be a best SAFI-1 route to P as
well as a best SAFI-4 route to P. Which packets get forwarded well as a best SAFI-4 route to P. Which packets get forwarded
according to the routes of which SAFI is then a matter of local according to the routes of which SAFI is then a matter of local
policy. policy.
Other implementations may treat the SAFI-1 and SAFI-4 routes for a Other implementations may treat the SAFI-1 and SAFI-4 routes for a
given prefix as comparable, such that the best route to prefix P is given prefix as comparable, such that the best route to prefix P is
either a SAFI-1 route or a SAFI-4 route, but not both. In either a SAFI-1 route or a SAFI-4 route, but not both. In such
implementations of this sort, if load balancing is done among a set implementations, if load-balancing is done among a set of equal cost
of equal cost routes, some of the equal cost routes may be SAFI-1 routes, some of the equal cost routes may be SAFI-1 routes and some
routes and some may be SAFI-4 routes. Whether this is allowed is may be SAFI-4 routes. Whether this is allowed is again a matter of
again a matter of local policy. local policy.
Some implementations may allow a single BGP session to carry UPDATES Some implementations may allow a single BGP session to carry UPDATES
of both SAFI-1 and SAFI-4; other implementations may disallow this. of both SAFI-1 and SAFI-4; other implementations may disallow this.
Some implementations that allow both SAFIs on the same session may
treat the receipt of a SAFI-1 route for prefix P on a given session
as an implicit withdrawal of a previous SAFI-4 route for prefix P on
that session, and vice versa. Other implementations may have
different behavior.
A BGP speaker may receive a SAFI-4 route over a given BGP session, A BGP speaker may receive a SAFI-4 route over a given BGP session,
but may have other BGP sessions for which SAFI-4 is not enabled. In but may have other BGP sessions for which SAFI-4 is not enabled. In
this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1 this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1
route and then propagate the result over the session on which SAFI-4 route and then propagate the result over the session on which SAFI-4
is not enabled. Whether this is done is a matter of local policy. is not enabled. Whether this is done is a matter of local policy.
These differences in the behavior of different implementations may
result in unexpected behavior or lack of interoperability. In some
cases, it may be difficult or impossible to achieve the desired
policies with certain implementations or combinations of
implementations.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign a codepoint for "Multiple Labels IANA is requested to assign a codepoint for "Multiple Labels
Capability" in the "BGP Capability Codes" registry, with this Capability" in the "BGP Capability Codes" registry, with this
document as the reference. document as the reference.
IANA is requested to modify the "BGP Capability Codes" registry to IANA is requested to modify the "BGP Capability Codes" registry to
mark Capability Code 4 ("Multiple routes to a destination") as mark Capability Code 4 ("Multiple routes to a destination") as
deprecated, with this document as the reference. deprecated, with this document as the reference.
skipping to change at page 19, line 20 skipping to change at page 19, line 37
There are various techniques one can use to constrain the There are various techniques one can use to constrain the
distribution of BGP UPDATE messages. If a BGP UPDATE advertises the distribution of BGP UPDATE messages. If a BGP UPDATE advertises the
binding of a particular (set of) label(s) to a particular address binding of a particular (set of) label(s) to a particular address
prefix, such techniques can be used to control the set of BGP prefix, such techniques can be used to control the set of BGP
speakers that are intended to learn of that binding. However, if BGP speakers that are intended to learn of that binding. However, if BGP
sessions do not provide privacy, other routers may learn of that sessions do not provide privacy, other routers may learn of that
binding. binding.
When a BGP speaker processes a received MPLS data packet whose top When a BGP speaker processes a received MPLS data packet whose top
label it advertised, there is no guarantee that the label in question label it advertised, there is no guarantee that the label in question
was put on the packet by a router that was intended to know about the was put on the packet by a router that was intended to know about
label binding. If a BGP speaker is using the procedures of this that label binding. If a BGP speaker is using the procedures of this
document, it may be useful for that speaker to distinguish its document, it may be useful for that speaker to distinguish its
"internal" interfaces from its "external" interfaces, and to avoid "internal" interfaces from its "external" interfaces, and to avoid
advertising the same labels to BGP speakers reached on internal advertising the same labels to BGP speakers reached on internal
interfaces as to BGP speakers reached on external interfaces. Then a interfaces as to BGP speakers reached on external interfaces. Then a
data packet can be discarded if its top label was not advertised over data packet can be discarded if its top label was not advertised over
the type of interface from which the packet was received. This the type of interface from which the packet was received. This
reduces the likelihood of forwarding packets whose labels have been reduces the likelihood of forwarding packets whose labels have been
"spoofed" by untrusted sources. "spoofed" by untrusted sources.
8. Acknowledgements 8. Acknowledgements
This draft obsoletes RFC 3107. We wish to think Yakov Rekhter, co- This draft obsoletes RFC 3107. We wish to thank Yakov Rekhter, co-
author of RFC 3107, for his work on that document. We also wish to author of RFC 3107, for his work on that document. We also wish to
thank Ravi Chandra, Enke Chen, Srihari R. Sangli, Eric Gray, and thank Ravi Chandra, Enke Chen, Srihari R. Sangli, Eric Gray, and
Liam Casey for their review of and comments on that document. Liam Casey for their review of and comments on that document.
We thank Alexander Okonnikov and David Lamparter for pointing out a We thank Alexander Okonnikov and David Lamparter for pointing out a
number of the errors in RFC 3107. number of the errors in RFC 3107.
We wish to thank Lili Wang and Kaliraj Vairavakkalai for their help We wish to thank Lili Wang and Kaliraj Vairavakkalai for their help
and advice during the preparation of this document. and advice during the preparation of this document.
We also thank Mach Chen, Bruno Decraene, Jie Dong, Adrian Farrel, We also thank Mach Chen, Bruno Decraene, Jie Dong, Adrian Farrel,
Jeff Haas, Jakob Heitz, Keyur Patel, Kevin Wang, and Lucy Yong for Jeff Haas, Jonathan Hardwick, Jakob Heitz, Alexander Okonnikov, Keyur
their review of and comments on this document. Patel, Kevin Wang, and Lucy Yong for their review of and comments on
this document.
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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
skipping to change at page 22, line 18 skipping to change at page 22, line 33
2015, <http://www.rfc-editor.org/info/rfc7432>. 2015, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911, "Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016, DOI 10.17487/RFC7911, July 2016,
<http://www.rfc-editor.org/info/rfc7911>. <http://www.rfc-editor.org/info/rfc7911>.
[TUNNEL-ENCAPS] [TUNNEL-ENCAPS]
Rosen, E., Patel, K., and G. Vandevelde, "The BGP Tunnel Rosen, E., Patel, K., and G. Vandevelde, "The BGP Tunnel
Encapulation Attribute", internet-draft draft-ietf-idr- Encapulation Attribute", internet-draft draft-ietf-idr-
tunnel-encaps-03, November 2016. tunnel-encaps-04, April 2017.
Author's Address Author's Address
Eric C. Rosen (editor) Eric C. Rosen
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States United States
Email: erosen@juniper.net Email: erosen@juniper.net
 End of changes. 38 change blocks. 
73 lines changed or deleted 87 lines changed or added

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