idnits 2.17.1 draft-marques-bgp4-cap-mp-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-16) 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 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 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: ---------------------------------------------------------------------------- -- 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 (April 1998) is 9498 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-1700' is mentioned on line 67, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) == Unused Reference: 'BGP-4' is defined on line 93, but no explicit reference was found in the text == Unused Reference: 'RFC1700' is defined on line 104, 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) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pedro R. Marques 3 Internet Draft cisco Systems, Inc. 4 Expiration Date: October 1998 5 April 1998 7 BGP-4 Capabilities Negotiation for BGP Multiprotocol Extensions 9 draft-marques-bgp4-cap-mp-01.txt 11 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 1. Abstract 32 This document defines the usage of the BGP-4 Capabilities Negotiation 33 parameter to negotiate the support for a particular Address Family, 34 Sub-address Family pair between BGP-4 speakers using BGP-4 35 Multiprotocol Extensions. 37 2. Overview 39 BGP-4 Multiprotocol Extensions [BGP-MP] define two optional non- 40 transitive attributes that enable BGP-4 to carry routing information 41 for multiple Network Layer protocols. Such attributes are ignored by 42 BGP-4 when unrecognized either because the peer doesn't implement or 43 is not configured to accept BGP-4 Multiprotocol Extensions or a given 44 (AFI, SAFI) pair. 46 The use of BGP-4 Capabilities Parameter [BGP-CAP] allows two peers to 47 negotiate the set of (AFI, SAFI) combinations supported on a 48 particular peering relationship. This document defines a Capability 49 Code that can be used for this purpose. 51 3. MP Capability Code 53 BGP speakers that wish to negotiate the set of (AFI, SAFI) pairs 54 availiable on a particular peering should use the MP_EXT Capability 55 Code (Type 0x01, in hexadecimal). 57 The Capability Value associated with the code is a 32 bit value, in 58 network byte-order, defined as: 60 0 7 15 23 31 61 +-------+-------+-------+-------+ 62 | AFI | Res. | SAFI | 63 +-------+-------+-------+-------+ 65 The use and meaning of this fields is as follows: 67 AFI - Address Family Identifier (16 bit) as defined in [RFC- 68 1700]. 70 Res. - Reserved (8 bit) field. Should be set to 0 by the sender 71 and ignored by the receiver. 73 SAFI - Subsequent Address Family Identifier (8 bit) field as 74 defined in [BGP-MP] 76 Each (AFI, SAFI) pair is encoded in the Capabilities Optional 77 Parameter of a BGP-4 OPEN message as a separate triple . This 79 allows the requester to identify which (AFI, SAFI) values are not 80 supported by the peer on the receipt of a Unsupported Capability 81 NOTIFICATION. 83 4. Security Considerations 85 Security issues are not discussed in this document. 87 5. Acknowledgements 89 To be supplied. 91 6. References 93 [BGP-4] "A Border Gateway Protocol 4 (BGP-4)", 94 Y. Rekhter and T. Li, RFC1771, March 1995. 96 [BGP-CAP] "Capabilities Negotiation with BGP-4", 97 R. Chandra and J. Scudder, Internet Draft, April 1998. 98 100 [BGP-MP] "Multiprotocol Extensions for BGP-4", 101 T. Bates, R. Chandra, D. Katz, and Y. Rekhter, 102 RFC 2283, February 1998. 104 [RFC1700] "Assigned Numbers", 105 J. Reynolds and J. Postel, RFC 1700, October 1994. 107 7. Author Information 109 Pedro R. Marques 110 cisco Systems, Inc. 111 170 West Tasman Drive 112 San Jose, CA 95134 113 email: roque@cisco.com