[OSPF] AD review of draft-ietf-ospf-prefix-link-attr-06
Alia Atlas <akatlas@gmail.com> Thu, 30 July 2015 19:22 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555351A905C; Thu, 30 Jul 2015 12:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 BCODECejr7e0; Thu, 30 Jul 2015 12:22:22 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEABE1A8A1D; Thu, 30 Jul 2015 12:22:18 -0700 (PDT)
Received: by oihq81 with SMTP id q81so27272037oih.2; Thu, 30 Jul 2015 12:22:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CwQcrpa4cS/2FqK0QAhU2NpcmKkvK3Vchawre6P3Cak=; b=kc2CSgqSQ0Jh7HEodP+5eocK/GswznJCJcKwZvIdsMo1gZKqGaZa8mCRyGruVW5RdO e287oLMTYiuIWssGgq+g8HtbSyxLEZE7IQw8+xQyLp+WUV/VvZ7pQ1zVwRZAk17aLPTq acgRVJtozedTZaPG51kBjLwAi662wP/NxKD93ktIQ3ME2PDarkQDbptC1BXVsFPygxLl QwXr60cBs/C11UzwLJxhtyXL/jsEMraf1A0w3oszAlBXMEAv0HQK7lcImvDlcTck6TcU ZXsyWCpeyD1gcgizNQkQ9GxKI/095NLpRJoMZp+aJzjKcVpV/mGObr2e3lLZ3fvrNNGa zj6A==
MIME-Version: 1.0
X-Received: by 10.202.175.199 with SMTP id y190mr9961043oie.22.1438284138324; Thu, 30 Jul 2015 12:22:18 -0700 (PDT)
Received: by 10.60.41.99 with HTTP; Thu, 30 Jul 2015 12:22:18 -0700 (PDT)
Date: Thu, 30 Jul 2015 15:22:18 -0400
Message-ID: <CAG4d1rfvc6NNO6cgX35Bo=+zA4K6dhL5bKkzL8ttuvCFxB2JSQ@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: draft-ietf-ospf-prefix-link-attr@ietf.org, OSPF List <ospf@ietf.org>, shraddha <shraddha@juniper.net>
Content-Type: multipart/alternative; boundary="001a113ceca426a818051c1c9fe9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/1bkJnB2V-96AAH5V5nbLv3oY6sc>
Subject: [OSPF] AD review of draft-ietf-ospf-prefix-link-attr-06
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2015 19:22:24 -0000
As is customary, I have done my AD review of draft-ietf-ospf-prefix-link-attr-06 before asking for IETF Last Call. First, thank you very much for your hard work on this draft. It is lovely to see needed work move quickly and have numerous interoperable implementations. I do have a number of minor issues on the draft - but all on the level of clarifications. Therefore, I have requested that IETF Last Call be started. Assuming good responsiveness on the part of the authors, a revised version that addresses my concerns can be on the IESG telechat on August 20. I do note that there are 6 authors on this draft. Please provide input - since I know that you all well aware that the limit is normally at most 5. One can identify a primary editor or two. This isn't pure process; the more authors listed on a draft, the longer it takes to handle AUTH48 - particularly when some are not as involved and do not respond rapidly and with full context. I make no judgement about the authors of this draft - who have clearly moved from pulling out the idea into a stand-alone draft and had a number of different implementations. My review comments are below. Thanks again for your hard work in getting this far! Minor issues: 1) On p. 6, it says " AF Address family for the prefix. Currently, the only supported value is 0 for IPv4 unicast." Please clarify VERY CLEARLY why this restriction exists. Not everyone reading this will be familiar with support for IPv6 in various protocols and we are really finally heading towards lots more IPv6. 2) On p. 6 and 8.: "The Instance field is an arbitrary value used to maintain multiple Extended Prefix Opaque LSAs. A maximum of 16777216 Extended Prefix Opaque LSAs may be sourced by a single OSPF instance.": This doesn't really give normative behavior. I assume that what you mean is that the advertising router has a number space for the Instance which has no significance outside of that advertising router and can have arbitrary values allocated from it. Each of these LSAs is identified uniquely by its Instance number. Please provide good text for what MUST be done and indicate that the value may be used for tie-breaking ("In this case, the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the smallest Instance is used by receiving OSPFv2 Routers. ") and there's an assumption that the values will be allocated from smallest to largest. 3) On p. 6 for the Route Type, it would be useful to have a reference to where these type values are pulled from. I'd also like to see some text about whether other values could be valid in the future and how so. For instance, I'm assuming that you are basically pulling the values from the OSPFv2 Link State (LS) Type ( http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-5 ) - so perhaps you could simply say so or clarify for what are valid values. 4) On p. 9: For Link-Type, could you also put a reference to the IANA registry? I'd prefer it to be clear that if (unlikely as it seems) there were a new Link-Type added, it would apply here too. 5) In Sec 5, pleaes add an RFC Editor note that Section 5 will be removed upon publication. That's the intent wtih RFC 6982. Thanks for including this section in the draft. If the information wants to move to the OSPF WG wiki, that would give it a place to survive after this draft is submitted to the RFC Editor. Nits: 6) In Sec 2, there's an "e.g., mapping server deployment". Could you add a reference? This tells me nothing... 7) In Sec 2, In the packet format, could you clarify Opaque type = 7? Same for on p.8 for opaque type = 8 ? 8) Since you are creating the registry for the TLVs, please clearly state that value 1 is being used earlier - instead of "suggested value" as on p.9 Regards, Alia
- [OSPF] AD review of draft-ietf-ospf-prefix-link-a… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-prefix-li… Acee Lindem (acee)
- Re: [OSPF] AD review of draft-ietf-ospf-prefix-li… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-prefix-li… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-prefix-li… t.petch
- Re: [OSPF] AD review of draft-ietf-ospf-prefix-li… Acee Lindem (acee)