idnits 2.17.1 draft-ietf-mpls-bgp4-mpls-02.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 61 lines 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 an Authors' Addresses Section. ** 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 119 has weird spacing: '...l, only the c...' == Line 120 has weird spacing: '...abel is withd...' == Line 123 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 152, 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: 9 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter 3 Internet Draft Cisco Systems 4 Expiration Date: August 1999 Eric Rosen 5 Cisco Systems 7 Carrying Label Information in BGP-4 9 draft-ietf-mpls-bgp4-mpls-02.txt 11 1. 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 2. Abstract 34 When a pair of Label Switch Routers (LSRs) that maintain BGP peering 35 with each other exchange routes, the LSRs also need to exchange label 36 mapping information for these routes. The exchange is accomplished by 37 piggybacking the label mapping information for a route in the same 38 BGP Update message that is used to exchange the route. This document 39 specifies the way in which this is done. 41 3. Overview 43 The Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH] 44 identifies situations in which the mapping between a label and a 45 route must be distributed between BGP peers. This document specifies 46 how this label mapping information is distributed. The label mapping 47 information is included in the BGP Update message that is used to 48 distribute the route. This is done by utilizing BGP-4 Multiprotocol 49 Extensions attribute [BGP-MP]. 51 4. Carrying Label Mapping Information 53 Label mapping information is carried as part of the Network Layer 54 Reachability Information (NLRI) in the Multiprotocol Extensions 55 attributes. Such NLRI is identified by using SAFI TBD. 57 The Network Layer Reachability information is encoded as one or more 58 triples of the form , whose fields are 59 described below: 61 +---------------------------+ 62 | Length (1 octet) | 63 +---------------------------+ 64 | Label (3 octets) | 65 +---------------------------+ 66 ............................. 67 +---------------------------+ 68 | Prefix (variable) | 69 +---------------------------+ 71 The use and the meaning of these fields are as follows: 73 a) Length: 75 The Length field indicates the length in bits of the address 76 prefix plus the label(s). 78 b) Label: 80 The Label field carries one or more labels (that corresponds to 81 the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 82 octets, where the high-order bit contains "Bottom of Stack" (as 83 defined in [MPLS-ENCAPS]). The following high-order three bits 84 must be zero. The remaining 20 bits contain the label value. 86 c) Prefix: 88 The Prefix field contains address prefixes followed by enough 89 trailing bits to make the end of the field fall on an octet 90 boundary. Note that the value of trailing bits is irrelevant. 92 The label(s) specified for a particular route (and associated with it 93 address prefix) must be assigned by the LSR which is identified by 94 the value of the Next Hop attribute of the route. 96 When a BGP speaker redistributes a route, the label(s) assigned to 97 that route must not be changed (except by omission), unless the 98 speaker changes the value of the Next Hop attribute of the route. 100 A BGP speaker can withdraw a previously advertised route (as well as 101 the binding between this route and a label) by either (a) advertising 102 a new route (and a label) with the same NLRI as the previously 103 advertised route, or (b) listing the NLRI of the previously 104 advertised route in the Withdrawn Routes field of an Update message. 105 The label information carried (as part of NLRI) in the Withdrawn 106 Routes field should be set to 0x800000. 108 5. Advertising Multiple Routes to a Destination 110 A BGP speaker may maintain (and advertise to its peers) more than one 111 route to a given destination, as long as each such route has its own 112 label(s). 114 The encoding described above allows a single BGP Update message to 115 carry multiple routes, each with its own label(s). 117 In the case where a BGP speaker advertises multiple routes to a 118 destination, if a route is withdrawn, and a label(s) is specified at 119 the time of withdrawal, only the corresponding route with the 120 corresponding label is withdrawn. If a route is withdrawn, and no 121 label is specified at the time of withdrawal, then only the 122 corresponding unlabeled route is withdrawn; the labeled routes are 123 left in place. 125 6. Capability Negotiation 127 A BGP speaker that uses Multiprotocol Extensions to carry label 128 mapping information should use the Capabilities Optional Parameter, 129 as defined in [BGP-CAP], to inform its peers about this capability. 130 The MP_EXT Capability Code, as defined in [BGP-MP], is used to 131 negotiate the (AFI, SAFI) pairs available on a particular connection. 133 A BGP speaker should not advertise this capability to another BGP 134 speaker unless there is a Label Switched Path (LSP) between the two 135 speakers. 137 A BGP speaker that is capable of handling multiple routes to a 138 destination (as described above) should use the Capabilities Optional 139 Paramter, as defined in [BGP-CAP], to inform its peers about this 140 capability. The value of this capability is TBD. 142 7. Security Considerations 144 Security issues are not discussed in this document. 146 8. Acknowledgements 148 To be supplied. 150 9. References 152 [BGP-4] "A Border Gateway Protocol 4 (BGP-4), Y. Rekhter, T. Li (RFC 153 1771) http://ds.internic.net/rfc/rfc1771.txt 155 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, et al, 156 Work in progress, http://www.internic.net/internet-drafts/draft- 157 ietf-idr-bgp4-cap-neg-03.txt 159 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, et al (RFC 160 2283) http://ds.internic.net/rfc/rfc2283.txt 162 [MPLS-ARCH], "A Proposed Architecture for MPLS", E. Rosen, et al, 163 Work in progress, http://www.internic.net/internet-drafts/draft- 164 ietf-mpls-arch-00.txt 166 [MPLS-ENCAPS], "MPLS Label Stack Encoding", E. Rosen, et al, Work in 167 progress, http://www.internic.net/internet-drafts/draft-ietf-mpls- 168 label-encaps-00.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