idnits 2.17.1 draft-ietf-mpls-bgp4-mpls-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MPLS-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2000) is 8869 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2283' is mentioned on line 100, but not defined ** Obsolete undefined reference: RFC 2283 (Obsoleted by RFC 2858) == Unused Reference: 'BGP-4' is defined on line 269, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) == Outdated reference: A later version (-05) exists of draft-ietf-idr-bgp4-cap-neg-04 ** Obsolete normative reference: RFC 2283 (ref. 'BGP-MP') (Obsoleted by RFC 2858) ** Obsolete normative reference: RFC 1966 (ref. 'BGP-RR') (Obsoleted by RFC 4456) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-06 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-07 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yakov Rekhter 2 Internet Draft Eric C. Rosen 3 Expiration Date: July 2000 Cisco Systems, Inc. 5 January 2000 7 Carrying Label Information in BGP-4 9 draft-ietf-mpls-bgp4-mpls-04.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 When BGP is used to distribute a particular route, it can be also be 35 used to distribute an MPLS label which is mapped to that route 36 [MPLS-ARCH]. This document specifies the way in which this is done. 37 The label mapping information for a particular route is piggybacked 38 in the same BGP Update message that is used to distribute the route 39 itself. 41 Table of Contents 43 1 Specification of Requirements .......................... 2 44 2 Overview ............................................... 2 45 3 Carrying Label Mapping Information ..................... 3 46 4 Advertising Multiple Routes to a Destination ........... 4 47 5 Capability Negotiation ................................. 5 48 6 When the BGP Peers are not Directly Adjacent ........... 5 49 7 Security Considerations ................................ 6 50 8 Acknowledgments ........................................ 7 51 9 References ............................................. 7 52 10 Author Information ..................................... 7 54 1. Specification of Requirements 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119. 60 2. Overview 62 When BGP is used to distribute a particular route, it can also be 63 used to distribute an MPLS label that is mapped to that route [MPLS- 64 ARCH]. This document specifies the way in which this is done. The 65 label mapping information for a particular route is piggybacked in 66 the same BGP Update message that is used to distribute the route 67 itself. 69 This can be useful in the following situations: 71 - If two immediately adjacent Label Switched Routers (LSRs) are 72 also BGP peers, then label distribution can be done without the 73 need for any other label distribution protocol. 75 - Suppose one's network consists of two "classes" of LSR: exterior 76 LSRs, which interface to other networks, and interior LSRs, which 77 serve only to carry traffic between exterior LSRs. Suppose that 78 the exterior LSRs are BGP speakers. If the BGP speakers 79 distribute MPLS labels to each other along with each route they 80 distribute, then as long as the interior routers support MPLS, 81 they need not receive any of the BGP routes from the BGP 82 speakers. 84 If exterior router A needs to send a packet to destination D, and 85 A's BGP next hop for D is exterior router B, and B has mapped 86 label L to D, then A first pushes L onto the packet's label 87 stack. A then consults its IGP to find the next hop to B, call 88 it C. If C has distributed to A an MPLS label for the route to 89 B, A can push this label on the packet's label stack, and then 90 send the packet to C. 92 If a set of BGP speakers are exchanging routes via a Route Reflector 93 [BGP-RR], then by piggybacking the label distribution on the route 94 distribution, one is able to use the Route Reflector to distribute 95 the labels as well. This improves scalability quite significantly. 96 Note that if the Route Reflector is not in the forwarding path, it 97 need not even be capable of forwarding MPLS packets. 99 Label distribution can be piggybacked in the BGP Update message by 100 using the BGP-4 Multiprotocol Extensions attribute [RFC 2283]. The 101 label is encoded into the NLRI field of the attribute, and the SAFI 102 ("Subsequent Address Family Identifier") field is used to indicate 103 that the NLRI contains a label. A BGP speaker may not use BGP to 104 send labels to a particular BGP peer unless that peer indicates, 105 through BGP Capability Negotiation, that it can process Update 106 messages with the specified SAFI field. 108 3. Carrying Label Mapping Information 110 Label mapping information is carried as part of the Network Layer 111 Reachability Information (NLRI) in the Multiprotocol Extensions 112 attributes. The AFI indicates, as usual, the address family of the 113 associated route. The fact that the NLRI contains a label is 114 indicated by using SAFI value 4 [assignment to be confirmed by IANA]. 116 The Network Layer Reachability information is encoded as one or more 117 triples of the form , whose fields are 118 described below: 120 +---------------------------+ 121 | Length (1 octet) | 122 +---------------------------+ 123 | Label (3 octets) | 124 +---------------------------+ 125 ............................. 126 +---------------------------+ 127 | Prefix (variable) | 128 +---------------------------+ 130 The use and the meaning of these fields are as follows: 132 a) Length: 134 The Length field indicates the length in bits of the address 135 prefix plus the label(s). 137 b) Label: 139 The Label field carries one or more labels (that corresponds to 140 the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 141 octets, where the high-order bit contains "Bottom of Stack" (as 142 defined in [MPLS-ENCAPS]). The following high-order three bits 143 must be zero. The remaining 20 bits contain the label value. 145 c) Prefix: 147 The Prefix field contains address prefixes followed by enough 148 trailing bits to make the end of the field fall on an octet 149 boundary. Note that the value of trailing bits is irrelevant. 151 The label(s) specified for a particular route (and associated with it 152 address prefix) must be assigned by the LSR which is identified by 153 the value of the Next Hop attribute of the route. 155 When a BGP speaker redistributes a route, the label(s) assigned to 156 that route must not be changed (except by omission), unless the 157 speaker changes the value of the Next Hop attribute of the route. 159 A BGP speaker can withdraw a previously advertised route (as well as 160 the binding between this route and a label) by either (a) advertising 161 a new route (and a label) with the same NLRI as the previously 162 advertised route, or (b) listing the NLRI of the previously 163 advertised route in the Withdrawn Routes field of an Update message. 164 The label information carried (as part of NLRI) in the Withdrawn 165 Routes field should be set to 0x800000. 167 4. Advertising Multiple Routes to a Destination 169 A BGP speaker may maintain (and advertise to its peers) more than one 170 route to a given destination, as long as each such route has its own 171 label(s). 173 The encoding described above allows a single BGP Update message to 174 carry multiple routes, each with its own label(s). 176 In the case where a BGP speaker advertises multiple routes to a 177 destination, if a route is withdrawn, and a label(s) is specified at 178 the time of withdrawal, only the corresponding route with the 179 corresponding label is withdrawn. If a route is withdrawn, and no 180 label is specified at the time of withdrawal, then only the 181 corresponding unlabeled route is withdrawn; the labeled routes are 182 left in place. 184 5. Capability Negotiation 186 A BGP speaker that uses Multiprotocol Extensions to carry label 187 mapping information should use the Capabilities Optional Parameter, 188 as defined in [BGP-CAP], to inform its peers about this capability. 189 The MP_EXT Capability Code, as defined in [BGP-MP], is used to 190 negotiate the (AFI, SAFI) pairs available on a particular connection. 192 A BGP speaker should not advertise this capability to another BGP 193 speaker unless there is a Label Switched Path (LSP) between the two 194 speakers. 196 A BGP speaker that is capable of handling multiple routes to a 197 destination (as described above) should use the Capabilities Optional 198 Parameter, as defined in [BGP-CAP], to inform its peers about this 199 capability. The value of this capability is TBD. 201 6. When the BGP Peers are not Directly Adjacent 203 Consider the following LSR topology: A--B--C--D. Suppose that D 204 distributes a label L to A. In this topology, A cannot simply push L 205 onto a packet's label stack, and then send the resulting packet to B. 206 D must be the only LSR that sees L at the top of the stack. Before A 207 sends the packet to B, it must push on another label, which was 208 distributed by B. B must replace this label with yet another label, 209 which was distributed by C. In other words, there must be an LSP 210 between A and D. If there is no such LSP, A cannot make use of label 211 L. This is true any time labels are distributed between non-adjacent 212 LSRs, whether that distribution is done by BGP or by some other 213 method. 215 This document does NOT specify any procedure for ensuring in real 216 time that label distribution between non-adjacent LSRs is done only 217 when the appropriate MPLS infrastructure exists in the network or 218 networks connecting the two LSRs. Ensuring that the proper 219 infrastructure exists is an issue for network management and 220 operation. 222 7. Security Considerations 224 When an LSR A is directly connected to an LSR B via a point-to-point 225 interface, then when A receives packets over that interface, it knows 226 that they come from B. This makes it easy for A to discard any 227 packets from B whose top labels are not among the labels that A 228 distributed to B. That is, A can easily ensure that B only uses 229 those labels which it is entitled to use. This technique can be used 230 to prevent "label spoofing", i.e., the situation in which an LSR 231 imposes a label which has not been properly distributed to it. 233 The procedures discussed in this document would commonly be used when 234 the label distribution peers are separated not merely by a point-to- 235 point link, but by an MPLS network. This means that when an LSR A 236 processes a labelled packet, it really has no way to determine which 237 other LSR B pushed on the top label. Hence it cannot tell whether 238 the label is one which B is entitled to use. In fact, when Route 239 Reflectors are in use, A may not even know the set of LSRs which 240 receive its label mappings. So the previous paragraph's technique 241 for preventing label spoofing does not apply. 243 It is possible though to use other techniques to avoid label spoofing 244 problems. If, for example, one never accepts labeled packets from 245 the network's "external" interfaces, and all the BGP-distributed 246 labels are advertised via IBGP, then there is no way for an untrusted 247 router to put a labeled packet into the network. One can generally 248 assume that one's IBGP peers (or the IBGP peers of one's Route 249 Reflector) will not attempt label spoofing, since they are all under 250 the control of a single administration. 252 This condition can actually be weakened significantly. One doesn't 253 need to refuse to accept all labeled packets from external 254 interfaces. One just needs to make sure that any labeled packet 255 received on an external interface has a top label which was actually 256 distributed out that interface. 258 Then a label spoofing problem would only exist if there are both 259 trusted and untrusted systems out the same interface. One way to 260 avoid this problem is simply to avoid this situation. 262 8. Acknowledgments 264 Thanks to Ravi Chandra, Enke Chen, Srihari Ramachandra, Eric Gray and 265 Liam Casey for their comments. 267 9. References 269 [BGP-4] RFC 1771, "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, 270 T. Li, 3/95 272 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, J. 273 , draft-ietf-idr-bgp4-cap-neg-04.txt, 9/99 275 [BGP-MP] RFC 2283, "Multiprotocol Extensions for BGP-4", T. Bates, R. 276 Chandra, D.Katz, Y. Rekhter, 2/98 278 [BGP-RR] RFC 1966, "BGP Route Reflection: An alternative to full mesh 279 IBGP", T. Bates, R. Chandra, 6/96. 281 [MPLS-ARCH] "Multiprotocol Label Switching Architecture"A Proposed 282 Architecture for MPLS", E. Rosen, A. Vishwanathan, R. Callon, draft- 283 ietf-mpls-arch-06.txt, 8/99. 285 [MPLS-ENCAPS] "MPLS Label Stack Encoding", E. Rosen, et al, draft- 286 ietf-mpls-label-encaps-07.txt, 9/99 288 10. Author Information 290 Yakov Rekhter 291 Cisco Systems, Inc. 292 170 West Tasman Drive 293 San Jose, CA 95134 294 email: yakov@cisco.com 296 Eric Rosen 297 Cisco Systems, Inc. 298 250 Apollo Drive 299 Chelmsford, MA 01824 300 email: erosen@cisco.com