idnits 2.17.1 draft-ietf-mpls-bgp4-mpls-00.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-25) 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 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 104 has weird spacing: '...l, only the c...' == Line 105 has weird spacing: '...abel is withd...' == Line 107 has weird spacing: '...n; the label...' -- 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 136, but no explicit reference was found in the text == Unused Reference: 'LDP' 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. 'CAP-MP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ENCAPS' Summary: 12 errors (**), 0 flaws (~~), 7 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: October 1998 Eric Rosen 5 Cisco Systems 7 Carrying Label Information in BGP-4 9 draft-ietf-mpls-bgp4-mpls-00.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 | Label (3 octets) | 61 +---------------------------+ 62 ............................. 63 +---------------------------+ 64 | Length (1 octet) | 65 +---------------------------+ 66 | Prefix (variable) | 67 +---------------------------+ 69 The use and the meaning of these fields are as follows: 71 a) Label: 73 The Label field carries one or more labels (that corresponds to 74 the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 75 octets, where the high-order bit contains "Bottom of Stack" (as 76 defined in [MPLS-ENCAPS]). The following high-order three bits 77 must be zero. The remaining 20 bits contain the label value. 79 b) Length: 81 The Length field indicates the length in bits of the address 82 prefix. A length of zero indicates a prefix that matches all 83 (as specified by the address family) addresses (with prefix, 84 itself, of zero octets). 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 encoding described above allows a single BGP Update message to 93 carry multiple routes, each with its own label(s). 95 The label(s) specified for a particular route (and associated with it 96 address prefix) must be assigned by the LSR which is identified by 97 the value of the Next Hop attribute of the route. 99 When a BGP speaker redistributes a route, the label(s) assigned to 100 that route must not be changed (except by omission), unless the 101 speaker changes the value of the Next Hop attribute of the route. 103 If a route is withdrawn, and a label(s) is specified at the time of 104 withdrawal, only the corresponding route with the corresponding 105 label is withdrawn. If a route is withdrawn, and no label is 106 specified at the time of withdrawal, then only the corresponding 107 unlabeled route is withdrawn; the labeled routes are left in 108 place. 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 5. Capability Negotiation 116 BGP-4 speakers using Multiprotocol Extensions to carry label mapping 117 information should use the Capabilities Optional Parameter as defined 118 in [BGP-CAP]. The MP_EXT Capability Code, as defined in [CAP-MP], is 119 used to negotiate the (AFI, SAFI) pairs available on a particular 120 connection. 122 A BGP speaker should not advertise this capability to another BGP 123 speaker unless there is a Label Switched Path (LSP) between the two 124 speakers. 126 6. Security Considerations 128 Security issues are not discussed in this document. 130 7. Acknowledgements 132 To be supplied. 134 8. References 136 [BGP-4] "A Border Gateway Protocol 4 (BGP-4), Y. Rekhter, T. Li (RFC 137 1771) http://ds.internic.net/rfc/rfc1771.txt 139 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, et al, 140 Work in progress, http://www.internic.net/internet-drafts/draft- 141 ietf-idr-bgp4-cap-neg-00.txt 143 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, et al (RFC 144 2283) http://ds.internic.net/rfc/rfc2283.txt 146 [CAP-MP] "BGP-4 Capabilities Negotiation for BGP Multiprotocol 147 Extensions", P. Marques, Work in progress, 148 http://ds.internic.net/internet-drafts/draft-marques-bgp4-cap-mp- 149 00.txt 151 [LDP] "LDP Specification", N. Feldman, et al, Work in progress 153 [MPLS-ARCH], "A Proposed Architecture for MPLS", E. Rosen, et al, 154 Work in progress, http://www.internic.net/internet-drafts/draft- 155 ietf-mpls-arch-00.txt 157 [MPLS-ENCAPS], "MPLS Label Stack Encoding", E. Rosen, et al, Work in 158 progress, http://www.internic.net/internet-drafts/draft-ietf-mpls- 159 label-encaps-00.txt 160 9. Author Information 162 Yakov Rekhter 163 Cisco Systems, Inc. 164 170 West Tasman Drive 165 San Jose, CA 95134 166 email: yakov@cisco.com 168 Eric Rosen 169 Cisco Systems, Inc. 170 250 Apollo Drive 171 Chelmsford, MA 01824 172 email: erosen@cisco.com