idnits 2.17.1 draft-ietf-mpls-bgp4-mpls-01.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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. ** There are 51 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([BGP-MP], [MPLS-ENCAPS], [BGP-CAP], [MPLS-ARCH], [BGP-4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 117 has weird spacing: '...l, only the c...' == Line 118 has weird spacing: '...abel is withd...' == Line 121 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) -- Missing reference section? 'MPLS-ARCH' on line 160 looks like a reference -- Missing reference section? 'BGP-MP' on line 157 looks like a reference -- Missing reference section? 'MPLS-ENCAPS' on line 164 looks like a reference -- Missing reference section? 'BGP-CAP' on line 153 looks like a reference -- Missing reference section? 'BGP-4' on line 150 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: February 1999 Eric Rosen 5 Cisco Systems 7 Carrying Label Information in BGP-4 9 draft-ietf-mpls-bgp4-mpls-01.txt 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 2. Abstract 32 When a pair of Label Switch Routers (LSRs) that maintain BGP peering 33 with each other exchange routes, the LSRs also need to exchange label 34 mapping information for these routes. The exchange is accomplished by 35 piggybacking the label mapping information for a route in the same 36 BGP Update message that is used to exchange the route. This document 37 specifies the way in which this is done. 39 3. Overview 41 The Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH] 42 identifies situations in which the mapping between a label and a 43 route must be distributed between BGP peers. This document specifies 44 how this label mapping information is distributed. The label mapping 45 information is included in the BGP Update message that is used to 46 distribute the route. This is done by utilizing BGP-4 Multiprotocol 47 Extensions attribute [BGP-MP]. 49 4. Carrying Label Mapping Information 51 Label mapping information is carried as part of the Network Layer 52 Reachability Information (NLRI) in the Multiprotocol Extensions 53 attributes. Such NLRI is identified by using Sub-AFI TBD. 55 The Network Layer Reachability information is encoded as one or more 56 triples of the form , whose fields are 57 described below: 59 +---------------------------+ 60 | Length (1 octet) | 61 +---------------------------+ 62 | Label (3 octets) | 63 +---------------------------+ 64 ............................. 65 +---------------------------+ 66 | Prefix (variable) | 67 +---------------------------+ 69 The use and the meaning of these fields are as follows: 71 a) Length: 73 The Length field indicates the length in bits of the address 74 prefix plus the label(s). 76 b) Label: 78 The Label field carries one or more labels (that corresponds to 79 the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 80 octets, where the high-order bit contains "Bottom of Stack" (as 81 defined in [MPLS-ENCAPS]). The following high-order three bits 82 must be zero. The remaining 20 bits contain the label value. 84 c) Prefix: 86 The Prefix field contains address prefixes followed by enough 87 trailing bits to make the end of the field fall on an octet 88 boundary. Note that the value of trailing bits is irrelevant. 90 The label(s) specified for a particular route (and associated with it 91 address prefix) must be assigned by the LSR which is identified by 92 the value of the Next Hop attribute of the route. 94 When a BGP speaker redistributes a route, the label(s) assigned to 95 that route must not be changed (except by omission), unless the 96 speaker changes the value of the Next Hop attribute of the route. 98 A BGP speaker can withdraw a previously advertised route (as well as 99 the binding between this route and a label) by either (a) advertising 100 a new route (and a label) with the same NLRI as the previously 101 advertised route, or (b) listing the NLRI of the previously 102 advertised route in the Withdrawn Routes field of an Update message. 103 The label information carried (as part of NLRI) in the Withdrawn 104 Routes field should be set to 0x800000. 106 5. Advertising Multiple Routes to a Destination 108 A BGP speaker may maintain (and advertise to its peers) more than one 109 route to a given destination, as long as each such route has its own 110 label(s). 112 The encoding described above allows a single BGP Update message to 113 carry multiple routes, each with its own label(s). 115 In the case where a BGP speaker advertises multiple routes to a 116 destination, if a route is withdrawn, and a label(s) is specified at 117 the time of withdrawal, only the corresponding route with the 118 corresponding label is withdrawn. If a route is withdrawn, and no 119 label is specified at the time of withdrawal, then only the 120 corresponding unlabeled route is withdrawn; the labeled routes are 121 left in place. 123 6. Capability Negotiation 125 A BGP speaker that uses Multiprotocol Extensions to carry label 126 mapping information should use the Capabilities Optional Parameter, 127 as defined in [BGP-CAP], to inform its peers about this capability. 128 The MP_EXT Capability Code, as defined in [BGP-MP], is used to 129 negotiate the (AFI, SAFI) pairs available on a particular connection. 131 A BGP speaker should not advertise this capability to another BGP 132 speaker unless there is a Label Switched Path (LSP) between the two 133 speakers. 135 A BGP speaker that is capable of handling multiple routes to a 136 destination (as described above) should use the Capabilities Optional 137 Paramter, as defined in [BGP-CAP], to inform its peers about this 138 capability. The value of this capability is TBD. 140 7. Security Considerations 142 Security issues are not discussed in this document. 144 8. Acknowledgements 146 To be supplied. 148 9. References 150 [BGP-4] "A Border Gateway Protocol 4 (BGP-4), Y. Rekhter, T. Li (RFC 151 1771) http://ds.internic.net/rfc/rfc1771.txt 153 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, et al, 154 Work in progress, http://www.internic.net/internet-drafts/draft- 155 ietf-idr-bgp4-cap-neg-00.txt 157 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, et al (RFC 158 2283) http://ds.internic.net/rfc/rfc2283.txt 160 [MPLS-ARCH], "A Proposed Architecture for MPLS", E. Rosen, et al, 161 Work in progress, http://www.internic.net/internet-drafts/draft- 162 ietf-mpls-arch-00.txt 164 [MPLS-ENCAPS], "MPLS Label Stack Encoding", E. Rosen, et al, Work in 165 progress, http://www.internic.net/internet-drafts/draft-ietf-mpls- 166 label-encaps-00.txt 168 10. Author Information 170 Yakov Rekhter 171 Cisco Systems, Inc. 172 170 West Tasman Drive 173 San Jose, CA 95134 174 email: yakov@cisco.com 176 Eric Rosen 177 Cisco Systems, Inc. 178 250 Apollo Drive 179 Chelmsford, MA 01824 180 email: erosen@cisco.com