idnits 2.17.1 draft-ietf-mpls-bgp4-mpls-03.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 118 has weird spacing: '...l, only the c...' == Line 119 has weird spacing: '...abel is withd...' == Line 122 has weird spacing: '... left in pl...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BGP-4' is defined on line 151, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-CAP' ** Obsolete normative reference: RFC 2283 (ref. 'BGP-MP') (Obsoleted by RFC 2858) -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ENCAPS' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yakov Rekhter 2 Internet Draft Cisco Systems 3 Expiration Date: March 2000 Eric Rosen 4 Cisco Systems 6 Carrying Label Information in BGP-4 8 draft-ietf-mpls-bgp4-mpls-03.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 When a pair of Label Switch Routers (LSRs) that maintain BGP peering 34 with each other exchange routes, the LSRs also need to exchange label 35 mapping information for these routes. The exchange is accomplished by 36 piggybacking the label mapping information for a route in the same 37 BGP Update message that is used to exchange the route. This document 38 specifies the way in which this is done. 40 3. Overview 42 The Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH] 43 identifies situations in which the mapping between a label and a 44 route must be distributed between BGP peers. This document specifies 45 how this label mapping information is distributed. The label mapping 46 information is included in the BGP Update message that is used to 47 distribute the route. This is done by utilizing BGP-4 Multiprotocol 48 Extensions attribute [BGP-MP]. 50 4. Carrying Label Mapping Information 52 Label mapping information is carried as part of the Network Layer 53 Reachability Information (NLRI) in the Multiprotocol Extensions 54 attributes. Such NLRI is identified by using SAFI TBD. 56 The Network Layer Reachability information is encoded as one or more 57 triples of the form , whose fields are 58 described below: 60 +---------------------------+ 61 | Length (1 octet) | 62 +---------------------------+ 63 | Label (3 octets) | 64 +---------------------------+ 65 ............................. 66 +---------------------------+ 67 | Prefix (variable) | 68 +---------------------------+ 70 The use and the meaning of these fields are as follows: 72 a) Length: 74 The Length field indicates the length in bits of the address 75 prefix plus the label(s). 77 b) Label: 79 The Label field carries one or more labels (that corresponds to 80 the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 81 octets, where the high-order bit contains "Bottom of Stack" (as 82 defined in [MPLS-ENCAPS]). The following high-order three bits 83 must be zero. The remaining 20 bits contain the label value. 85 c) Prefix: 87 The Prefix field contains address prefixes followed by enough 88 trailing bits to make the end of the field fall on an octet 89 boundary. Note that the value of trailing bits is irrelevant. 91 The label(s) specified for a particular route (and associated with it 92 address prefix) must be assigned by the LSR which is identified by 93 the value of the Next Hop attribute of the route. 95 When a BGP speaker redistributes a route, the label(s) assigned to 96 that route must not be changed (except by omission), unless the 97 speaker changes the value of the Next Hop attribute of the route. 99 A BGP speaker can withdraw a previously advertised route (as well as 100 the binding between this route and a label) by either (a) advertising 101 a new route (and a label) with the same NLRI as the previously 102 advertised route, or (b) listing the NLRI of the previously 103 advertised route in the Withdrawn Routes field of an Update message. 104 The label information carried (as part of NLRI) in the Withdrawn 105 Routes field should be set to 0x800000. 107 5. Advertising Multiple Routes to a Destination 109 A BGP speaker may maintain (and advertise to its peers) more than one 110 route to a given destination, as long as each such route has its own 111 label(s). 113 The encoding described above allows a single BGP Update message to 114 carry multiple routes, each with its own label(s). 116 In the case where a BGP speaker advertises multiple routes to a 117 destination, if a route is withdrawn, and a label(s) is specified at 118 the time of withdrawal, only the corresponding route with the 119 corresponding label is withdrawn. If a route is withdrawn, and no 120 label is specified at the time of withdrawal, then only the 121 corresponding unlabeled route is withdrawn; the labeled routes are 122 left in place. 124 6. Capability Negotiation 126 A BGP speaker that uses Multiprotocol Extensions to carry label 127 mapping information should use the Capabilities Optional Parameter, 128 as defined in [BGP-CAP], to inform its peers about this capability. 129 The MP_EXT Capability Code, as defined in [BGP-MP], is used to 130 negotiate the (AFI, SAFI) pairs available on a particular connection. 132 A BGP speaker should not advertise this capability to another BGP 133 speaker unless there is a Label Switched Path (LSP) between the two 134 speakers. 136 A BGP speaker that is capable of handling multiple routes to a 137 destination (as described above) should use the Capabilities Optional 138 Paramter, as defined in [BGP-CAP], to inform its peers about this 139 capability. The value of this capability is TBD. 141 7. Security Considerations 143 Security issues are not discussed in this document. 145 8. Acknowledgements 147 To be supplied. 149 9. References 151 [BGP-4] "A Border Gateway Protocol 4 (BGP-4), Y. Rekhter, T. Li (RFC 152 1771) http://ds.internic.net/rfc/rfc1771.txt 154 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, et al, 155 Work in progress, http://www.internic.net/internet-drafts/draft- 156 ietf-idr-bgp4-cap-neg-03.txt 158 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, et al (RFC 159 2283) http://ds.internic.net/rfc/rfc2283.txt 161 [MPLS-ARCH], "A Proposed Architecture for MPLS", E. Rosen, et al, 162 Work in progress, http://www.internic.net/internet-drafts/draft- 163 ietf-mpls-arch-06.txt 165 [MPLS-ENCAPS], "MPLS Label Stack Encoding", E. Rosen, et al, Work in 166 progress, http://www.internic.net/internet-drafts/draft-ietf-mpls- 167 label-encaps-05.txt 169 10. Author Information 171 Yakov Rekhter 172 Cisco Systems, Inc. 173 170 West Tasman Drive 174 San Jose, CA 95134 175 email: yakov@cisco.com 177 Eric Rosen 178 Cisco Systems, Inc. 179 250 Apollo Drive 180 Chelmsford, MA 01824 181 email: erosen@cisco.com