Re: [pim] AD Review of draft-ietf-pim-drlb-10

"Mankamana Mishra (mankamis)" <mankamis@cisco.com> Mon, 26 August 2019 15:40 UTC

Return-Path: <mankamis@cisco.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20557120115; Mon, 26 Aug 2019 08:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jf7Mj9rK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=r9ZeDdki
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-LSB5--T5-g; Mon, 26 Aug 2019 08:40:10 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FA5120071; Mon, 26 Aug 2019 08:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13660; q=dns/txt; s=iport; t=1566834010; x=1568043610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xhcFjhhuqIgneHTiUQgbxoBqTKAXClxuZ1II5lLa0+Y=; b=jf7Mj9rKDboXbF+TG1f0Qjf/GwgGqT7MSN/f2DQazw7TUbeDXiBLQj9h fsXwmRsH/Qb4H2aT6tawfnXXCdzuxJax57FmoQCcRl5k0ca3SZ64Gt7KL eZvvFeMvniPc7GGYCNjT3/KjRe49YnifzO/cA1ZE0idCYeArx3CzGxco/ I=;
IronPort-PHdr: 9a23:SZ2T5BNwEslmPbGzHSsl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBj+JfjpZik7B+xJVURu+DewNk0GUMs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ALAABt/GNd/4gNJK1kGgEBAQEBAgEBAQEHAgEBAQGBUwUBAQEBCwGBRCQFJwNtViAECyoKhBeDRwOEUoYbgjcliWCOCIEuFIEQA1QJAQEBDAEBIwoCAQGEPwIXglAjNAkOAgoBAQQBAQECAQYEbYUtDIVKAQEBAQMSEREMAQEyBQELBAIBCA4DAwECAwImAgICHxEVCAgCBAENBSKDAAGBagMdAQIMnVYCgTiIYXOBMoJ7AQEFgTIBg0wNC4IWAwaBDCgBhHyFV4EeGIFAP4EQAScME4F8UD6CGkcCgSkRJyaCZTKCJowgEg6CXY4bjUktQAkCgh6GaoUBhF6DehuCMocwjm2NaIdrgX+OPAIEAgQFAg4BAQWBUDiBWHAVOyoBgkGCQgsBF4EEAQeCQ4IGgw6FP3IBgSiLVYExAYEgAQE
X-IronPort-AV: E=Sophos;i="5.64,433,1559520000"; d="scan'208";a="314752716"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 15:40:07 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x7QFe2RN011719 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Aug 2019 15:40:07 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 10:40:05 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 11:40:04 -0400
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 10:40:04 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dDsysK94+Paz/e298k5fjpV+Vr6oLElitJ5kz9eQIb3Q7FrVrNgiiJCjt7DaJXAgW0w5t2u0tzLpMWual6N5mzGB/oS/Fsaefwzgp05IWepais97zg0cbhIq4wRzvTfZF36ezBIFHve6kKJtd0OUZ/nzgU9Ovw4tLroeFbBx98PYQ2q+F8BbRB1Oe8J/A+sEk+sVXW+6+rhwRUFYRoI2VCaLOqtBJC6MlZhiWdpVET2XdNTPqal5fHvn0urHilyK3nt+Px8ZjK3a0yiDvw/8zJw1sVaiiGaZ72S0o/zGZdAauCrXtoAVS9EI11B4l5DhA4CfJ4Mb+N69eSPrXBa+vg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xhcFjhhuqIgneHTiUQgbxoBqTKAXClxuZ1II5lLa0+Y=; b=I54j6maM+3OBUM9Aeu5hLn56aSf4nyeW1Caq3kVlKM1tJuYYCrpSkCpa4y4Riwgp43BUf1hA2dRyZKCPcThRTSJpfQee9OLMfk2OhzTiae2ds5deaxQPoWdcKEKfRfJEuIw1B2/1d3dZgwUkPOTL9wdkp3pPPbGQ0QZoqkQ+U6HWTXnRqxGlNSH0PipsSmS5w8rVHDtSkNNoPgzv2ttgzf3uCEj3zMca/z/RrrETf2XIRzp6Rq0ZN4KluAHz+dOtjY7iORfZTPDEmh4swIVI55XffkgQI8pHWlenIbHUV1sX9LW2kAfG9azXKeItlxiKIQqCar/vbB0BJhudnf6gTg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xhcFjhhuqIgneHTiUQgbxoBqTKAXClxuZ1II5lLa0+Y=; b=r9ZeDdki5VGqHdXr03Auz2nrxAYp87LKTKYvEzngxRE5xIeqEEbEes8R8txVvZtkTfH92o+/KGXoGpeEJTyJ7WRg/T5AbWAVUnlVtR4UrE+TAxFGXXq36dxxFOOuyQhaYC1TtTmyxTFaGRZRRrYLn+wXKq+p5SFjfXfF6MhxoUo=
Received: from BYAPR11MB3685.namprd11.prod.outlook.com (20.178.237.158) by BYAPR11MB3240.namprd11.prod.outlook.com (20.177.184.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Mon, 26 Aug 2019 15:40:02 +0000
Received: from BYAPR11MB3685.namprd11.prod.outlook.com ([fe80::cc1b:6af7:8174:e33a]) by BYAPR11MB3685.namprd11.prod.outlook.com ([fe80::cc1b:6af7:8174:e33a%6]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 15:40:02 +0000
From: "Mankamana Mishra (mankamis)" <mankamis@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-pim-drlb@ietf.org" <draft-ietf-pim-drlb@ietf.org>
CC: "pim-chairs@ietf.org" <pim-chairs@ietf.org>, "pim@ietf.org" <pim@ietf.org>, Mike McBride <mmcbride7@gmail.com>
Thread-Topic: AD Review of draft-ietf-pim-drlb-10
Thread-Index: AQHVKFDvO19swEHu50SBN++o1NtrTacN7FsA//+WtwA=
Date: Mon, 26 Aug 2019 15:40:02 +0000
Message-ID: <96800DA5-0F6B-435C-8874-D7B483EA20B9@cisco.com>
References: <CAMMESszYeVa9_2EMQjNCUP-8PzK3g_Zbv0cQ5vi7nA8j4Kp9Fw@mail.gmail.com> <CAMMESswGm4Qe514m1XSdbZEAHWoE-FyW1=fDriDCB-FvsuLLNA@mail.gmail.com>
In-Reply-To: <CAMMESswGm4Qe514m1XSdbZEAHWoE-FyW1=fDriDCB-FvsuLLNA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mankamis@cisco.com;
x-originating-ip: [128.107.241.167]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 04413d31-18a1-4146-e8d8-08d72a3ba93b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3240;
x-ms-traffictypediagnostic: BYAPR11MB3240:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR11MB3240A69FA721E56BFA3FB2B8DFA10@BYAPR11MB3240.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(396003)(136003)(346002)(51444003)(13464003)(189003)(199004)(66946007)(6512007)(66066001)(966005)(478600001)(6306002)(76116006)(6436002)(5660300002)(53936002)(7736002)(305945005)(6246003)(25786009)(26005)(2616005)(6486002)(71190400001)(11346002)(71200400001)(4326008)(66574012)(33656002)(446003)(476003)(36756003)(54906003)(486006)(14454004)(86362001)(66446008)(64756008)(53546011)(66476007)(6506007)(66556008)(99286004)(102836004)(2906002)(186003)(110136005)(8676002)(229853002)(2501003)(316002)(81156014)(81166006)(76176011)(8936002)(3846002)(6116002)(256004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3240; H:BYAPR11MB3685.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rxEcScJz9a2/wHVExuFhGb7hvbHLHI0dluSI9JB9C8aot10FDFIB/LhLQihy4y7+vZbfmDdekp9W0SmDFO8Csw21OK05r8491zzCitksnZZWG7gCDhI5ORuluP38c+JUlZ3HB9P6H1wVXm3pUV2mXIhlXftsB8p0m7G5PmlZ3acmuqwS0s3YGGKKXONtlo7lrxXl66p6tynTUVdRManHUZO66SsviS4RNUBc2V0mDgt/K/GGftZE+neMDQdI6YiMOcelQkDQkDTaHzNl/u566RgqIfv/MlJ/0ju//S2zcTb5epBnGqGspyVQ+fqfSIqHh+GQfOdGs/PJqB1wMbpfUnZdn07JEzyt0BsW6LClr83HcSH4HVKpJ82utjP1blSk7ThI06AJGqw/ZHoSHtxtqYmsj+xYdOVScE5NOifi7KQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <458B62A1B72BDD4D81FD3EBC3749B19A@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 04413d31-18a1-4146-e8d8-08d72a3ba93b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 15:40:02.5138 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sDigqXGLiSno1KqUy5ruorJbbrNf9tJBL/bVivFes6aytVtuHKkD0BjCUrdupogpXiYvoGNd55UAXz7ndYB1RQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3240
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/KkLl4L6eLjVF-xoEaTC0_XeOx2M>
Subject: Re: [pim] AD Review of draft-ietf-pim-drlb-10
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 15:40:13 -0000

Hi Alvaro, 
Me & Stig would go over your comments and address it soon. 

Thanks 
Mankamana 
 

-----Original Message-----
From: Alvaro Retana <aretana.ietf@gmail.com>
Date: Monday, August 26, 2019 at 7:57 AM
To: "draft-ietf-pim-drlb@ietf.org" <draft-ietf-pim-drlb@ietf.org>
Cc: "pim-chairs@ietf.org" <pim-chairs@ietf.org>, "pim@ietf.org" <pim@ietf.org>, Mike McBride <mmcbride7@gmail.com>
Subject: Re: AD Review of draft-ietf-pim-drlb-10
Resent-From: <alias-bounces@ietf.org>
Resent-To: <yiqun.cai@alibaba-inc.com>, <hou@cisco.com>, <svallepa@cisco.com>, <mankamis@cisco.com>, <stig@cisco.com>, <andy.da.green@bt.com>
Resent-Date: Monday, August 26, 2019 at 7:57 AM

    Hi!
    
    It’s been a while since this review…any thoughts?
    
    Thanks!
    
    Alvaro.
    
    On June 21, 2019 at 12:46:30 PM, Alvaro Retana (aretana.ietf@gmail.com)
    wrote:
    
    Dear authors:
    
    First of all, thank you for reviving this work!!
    
    I just finished reading the document and have significant concerns (please
    see details in line).  In fact, I am pointing at the same general issue
    that the original AD review [1] did: under-specification.  Adding text in
    6.2 has resulted in behavior being specified (inconsistently!) more than
    once.
    
    Also, the specification of the Hash Algorithm is included in §4 (Functional
    Overview).  Not being in an appropriately named section is significant.
    Please move this part to §6 (Protocol Specification), or maybe its own
    section.
    
    Even though there is much work needed, I don't want to return this document
    to the WG and risk more delay.  While some major issues will require
    changes, I think that many of them are about the structure of the
    document.  If needed, I will rely on Mike (Chair/Shepherd) to coordinate
    further WG review.
    
    Thanks!
    
    Alvaro.
    
    [1] https://mailarchive.ietf.org/arch/msg/pim/K61q4--5ZBb9RTMkeud-5MnmuOw
    
    
    [Line numbers from id-nits.]
    
    
    ...
    90 1.  Introduction
    
    92   On a multi-access LAN such as an Ethernet, one of the PIM routers is
    93   elected as a DR.  The PIM DR has two roles in the PIM-SM protocol.
    94   On the first hop LAN, the PIM DR is responsible for registering an
    95   active source with the Rendezvous Point (RP) if the group is
    96   operating in PIM-SM.  On the last hop LAN, the PIM DR is responsible
    97   for tracking local multicast listeners and forwarding to these
    98   listeners if the group is operating in PIM-SM.
    
    [minor] The first reference to rfc7761 is below, when talking about DR
    election.  Consider moving that reference to this first paragraph so that
    the stage is set early.
    
    [nit] I know DR was extended in the Abstract, the acronym is used above and
    the extended version again below...  Please extend DR above and use the
    contracted form elsewhere.
    
    
    ...
    114   Assume R1 is elected as the Designated Router.  According to
    115   [RFC7761], R1 will be responsible for forwarding traffic to that LAN
    116   on behalf of any local members.  In addition to keeping track of IGMP
    117   and MLD membership reports, R1 is also responsible for initiating the
    118   creation of source and/or shared trees towards the senders or the
    119   RPs.
    
    [minor] We need Informative references to IGMP and MLD.
    
    121   Forcing sole data plane forwarding responsibility on the PIM DR
    122   uncovers a limitation in the protocol.  In comparison, even though an
    123   OSPF DR or an IS-IS DIS handles additional duties while running the
    124   OSPF or IS-IS protocols, they are not required to be solely
    125   responsible for forwarding packets for the network.  On the other
    126   hand, on a last hop LAN, only the PIM DR is asked to forward packets
    127   while the other routers handle only control traffic (and perhaps drop
    128   packets due to RPF failures).  Hence the forwarding load of a last
    129   hop LAN is concentrated on a single router.
    
    [minor] "In comparison..."  I think that comparing the PIM DR to an OSPF
    DR/IS-IS DIS is completely out of place since the justification for this
    work is to share forwarding responsibilities...and the IGP DR/DIS are not
    responsible for forwarding at all!  IOW, the comparison doesn't make sense.
    
    [minor] RPF failures are only mentioned here.  Either expand on them and
    explain why they are relevant to this work, or remove the text to avoid
    confusion.
    
    131   This leads to several issues.  One of the issues is that the
    132   aggregated bandwidth will be limited to what R1 can handle towards
    133   this particular interface.  It is very common that the last hop LAN
    134   consists of switches that run IGMP/MLD or PIM snooping.  This allows
    135   the forwarding of multicast packets to be restricted only to segments
    136   leading to receivers who have indicated their interest in multicast
    137   groups using either IGMP or MLD.  The emergence of the switched
    138   Ethernet allows the aggregated bandwidth to exceed, sometimes by a
    139   large number, that of a single link.  For example, let us modify
    140   Figure 1 and introduce an Ethernet switch in Figure 2.
    
    [nit] "this particular interface"  Which interface?  I'm sure you mean the
    one to the core networks...but please be explicit.
    
    [minor] "IGMP/MLD or PIM snooping"  We need a reference.
    
    
    ...
    184   There is a limitation in the hash algorithm used in this document,
    185   but this document provides the option to have different and more
    186   consistent hash algorithms in the future.
    
    [minor] I think that the limitations discussion should be left to §4.3.1.
    IOW, I suggest taking this paragraph out.
    
    
    ...
    193 2.  Terminology
    
    195   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    196   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    197   document are to be interpreted as described in [RFC2119].
    
    [major] Please use the rfc8174 template.
    
    
    ...
    204   o  GDR: GDR stands for "Group Designated Router".  For each multicast
    205      flow, either a (*,G) for ASM, or an (S,G) for SSM, a hash
    206      algorithm (described below) is used to select one of the routers
    207      as a GDR.  The GDR is responsible for initiating the forwarding
    208      tree building process for the corresponding multicast flow.
    
    [nit] s/GDR: GDR stands for "Group Designated Router"./GDR: Group
    Designated Router.
    
    [minor] ASM needs to be expanded
    
    210   o  GDR Candidate: a last hop router that has the potential to become
    211      a GDR.  A GDR Candidate must have the same DR priority and must
    212      run the same GDR election hash algorithm as the DR router.  It
    213      must send and process new PIM Hello Options as defined in this
    214      document.  There might be more than one GDR Candidate on a LAN,
    215      but only one can become GDR for a specific multicast flow.
    
    [major] This paragraph uses "must" several times.  Should that be Normative
    language?
    
    [??] Why is it a requirement to have the same DR priority?  It seems to me
    that there would be more options and even better load sharing if more
    routers could be GDR.
    
    
    ...
    229 4.  Functional Overview
    ...
    256   Hash Masks are defined for Source, Group and RP separately, in order
    257   to handle PIM ASM/SSM.  The masks, as well as a sorted list of GDR
    258   Candidate Addresses, are announced by the DR in a new DR Load
    259   Balancing GDR (DRLBGDR) PIM Hello Option.
    
    [nit / personal opinion] The abbreviations for the new Options are awful --
    I keep having to think about the meaning and whether they are spelled
    correctly at every step.  Perhaps something reader-friendly acronyms would
    be better.  Suggestions:
    
    - DR Load Balancing Capability PIM Hello Option: LB Option
    - DR Load Balancing GDR PIM Hello Option: GDR List Option (maybe even GL)
    
    261   A hash algorithm based on the announced Source, Group, or RP masks
    262   allows one GDR to be assigned to a corresponding multicast state.
    263   And that GDR is responsible for initiating the creation of the
    264   multicast forwarding tree for multicast traffic.
    
    [major] Is there a possibility that the assigned GDR for a specific
    multicast state can't fulfill its duties?  This document assumes that all
    the GDRs are able to service all states...but that may not be true.
    Because every GDR candidate calculates who the GDR is for a specific state,
    it may never know what an alternate GDR is not able to forward traffic.
     [Does this make sense?]
    
    266 4.1.  GDR Candidates
    
    268   GDR is the new concept introduced by this specification.  GDR
    269   Candidates are routers eligible for GDR election on the LAN.  To
    270   become a GDR Candidate, a router MUST support this specification,
    271   have the same DR priority and run the same GDR election hash
    272   algorithm as the DR on the LAN.
    
    [nit] There is a lot of repetition in the text...for example, all the
    contents on this paragraph were already mentioned in the last section...
    Cleaning up the text would be nice.
    
    [major] "To become a GDR Candidate, a router MUST support this
    specification..."  First of all, this is an obvious statement: the GDR is
    defined in this document.  Second, there's no Normative value in using MUST