idnits 2.17.1 draft-ietf-idmr-pimv2-dr-priority-00.txt: 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-23) 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 1 longer page, the longest (page 1) being 89 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. 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.) -- 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: 'PIM' is defined on line 86, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-ietf-idmr-pim-sm-specv2 (ref. 'PIM') Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Liming Wei 3 INTERNET-DRAFT cisco Systems, Inc 4 Dino Farinacci 5 March 4, 1998 cisco Systems, Inc 6 Expires: in 6 months 8 PIM Version 2 DR Election Priority Option 9 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 the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This draft specifies the DR Election Priority Option in PIM version 2 32 Hello messages. 34 1. Introduction 36 The current PIM specification uses an address-based designated router 37 (DR) election algorithm. The router with the largest IP address is 38 always elected as the DR. 40 The DR Election Priority option is used when people want to have 41 control over which router is elected as the DR, irrespective of the 42 address of routers on the same LAN. This is needed on LANs where new 43 routers can be added and configured by different operators. 45 2. DR Election Priority Option 47 The DR election priority is a 32-bit unsigned number. The numerically 48 larger priority is always preferred. The DR election priority is used 49 only when all routers on the LAN include this option in their Hellos. 51 If no DR election priority option is specified in a Hello 52 message, the Hello sender is deemed not capable of handling the DR 53 election priority option. When such a hello message is received, the 54 neighbor with the highest IP address is elected the DR. This way new 55 systems can interoperate with older systems in the old way. 57 The DR election priority received in a Hello is kept until the 58 next Hello from the same system arrives. The newly received priority 59 replaces the cached priority for the same neighbor. 61 An implementation capable of doing this option should always include 62 it in the Hellos even if no DR election priority is explicitly 63 configured. The default priority is 1. 65 The following is the format of this option. 67 OptionType: 19 68 OptionLength: 4 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | OptionType = 19 | OptionLength = 4 | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 73 | Priority | 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 Priority: 32-bit 77 Priority value. This should be treated as the higher order bits 78 to the address during DR election. 80 3. Acknowledgmentssss 82 Pavlin Radoslavov commented on a previous version of this draft. 84 4. References 86 [PIM] draft-ietf-idmr-pim-sm-specv2-00.txt