Re: [OSPF] AD review of draft-ietf-ospf-prefix-link-attr-06
"Acee Lindem (acee)" <acee@cisco.com> Tue, 04 August 2015 13:12 UTC
Return-Path: <acee@cisco.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 8DB8A1A903E; Tue, 4 Aug 2015 06:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 4chv1iD_abxi; Tue, 4 Aug 2015 06:12:40 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E494D1A9084; Tue, 4 Aug 2015 06:12:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9356; q=dns/txt; s=iport; t=1438693959; x=1439903559; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=G9NaqyknugRfK/EdzEoXFz7j2UluFecXx2N4lFFZ48c=; b=m0JNonNN3hnNL3HjsfaFxLnkQWPYQOx+118FSxlpDi1lcgwiGLojaO5V Gx6BokrSODpK+7QB4qtD0FcGmd281nKoZ6naTqonEa7Cf8ACabLbkwG9V lmmjoN1LBQSwTz6BnUX4ZVd7ECxPPkJpNBZ32I8AfsCzYCcluiBDoVg0A 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BxAwBKucBV/5pdJa1RCoMaVGkGgx25QgmBegyFdwIcgRU4FAEBAQEBAQGBCoQjAQEBAwEBAQEgEToXBAIBCBEBAgEBAQMCIwMCAgIfBgsUAQIGCAIEARIJiBADCggNtDGQeg2FNwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIootgk+BXAUNGBgiBoJjgUMFhxmNYgGKZIFrgUeEIow8g0yDZCaDfW8BgQVCgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,608,1432598400"; d="scan'208";a="15701343"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 04 Aug 2015 13:12:38 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t74DCcBZ029955 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2015 13:12:38 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 4 Aug 2015 08:12:37 -0500
Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-rcd-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Tue, 4 Aug 2015 08:12:37 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Tue, 4 Aug 2015 08:12:37 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "t.petch" <ietfc@btconnect.com>, Alia Atlas <akatlas@gmail.com>, "draft-ietf-ospf-prefix-link-attr@ietf.org" <draft-ietf-ospf-prefix-link-attr@ietf.org>, OSPF List <ospf@ietf.org>, shraddha <shraddha@juniper.net>
Thread-Topic: [OSPF] AD review of draft-ietf-ospf-prefix-link-attr-06
Thread-Index: AQHQyv0RUgMixNXA9027FbXFLKfCEp331PaAgAPulqOAACWuAA==
Date: Tue, 04 Aug 2015 13:12:37 +0000
Message-ID: <D1E6325F.2A29C%acee@cisco.com>
References: <CAG4d1rfvc6NNO6cgX35Bo=+zA4K6dhL5bKkzL8ttuvCFxB2JSQ@mail.gmail.com> <D1E2B485.2A028%acee@cisco.com> <015201d0ceac$e62dc380$4001a8c0@gateway.2wire.net>
In-Reply-To: <015201d0ceac$e62dc380$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.28]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3FDA41841C187F4BA0FD5E72C4A24CB9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/g-J6lfX67yxK0yRg884pUwkATRU>
Subject: Re: [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: Tue, 04 Aug 2015 13:12:42 -0000
Hi Tom, On 8/4/15, 7:57 AM, "t.petch" <ietfc@btconnect.com> wrote: >Acee > >On the IANA question, you might find 5226bis of value, particularly >sections 7 and 8. > >That I-D also introduces a clarification to the terminology so that >Open Shortest Path First v2 (OSPFv2) Parameters >is a Group and >OSPFv2 Link State (LS) Type >is a registry, something which you might incorporate. > >'existing OSPF IANA registry' I find ambiguous. I agree - this will be clarified for all 4 of the new registries in the 08 version of the draft. Thanks, Acee > > Tom Petch > >----- Original Message ----- >From: "Acee Lindem (acee)" <acee@cisco.com> >To: "Alia Atlas" <akatlas@gmail.com>; ><draft-ietf-ospf-prefix-link-attr@ietf.org>; "OSPF List" ><ospf@ietf.org>; "shraddha" <shraddha@juniper.net> >Sent: Saturday, August 01, 2015 10:54 PM >Subject: Re: [OSPF] AD review of draft-ietf-ospf-prefix-link-attr-06 > > >> Hi Alia, >> Thanks for the review. >> >> From: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> >> Date: Thursday, July 30, 2015 at 2:22 PM >> To: >"draft-ietf-ospf-prefix-link-attr@ietf.org<mailto:draft-ietf-ospf-prefix >-link-attr@ietf.org>" ><draft-ietf-ospf-prefix-link-attr@ietf.org<mailto:draft-ietf-ospf-prefix >-link-attr@ietf.org>>, OSPF WG List ><ospf@ietf.org<mailto:ospf@ietf.org>>, shraddha ><shraddha@juniper.net<mailto:shraddha@juniper.net>> >> Subject: AD review of draft-ietf-ospf-prefix-link-attr-06 >> >> 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. >> >> We’ve already made one pass on pruning the authors and since we are >only one over, I’d like to leave it as is. >> >> >> >> 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. >> >> I will clarify. There are basically two reasons. The first is that we >really didn’t want to specify more than was necessary in this base >document. The second is that we have OSPFv3 for IPv6. So, you may ask >why we have this at all. The reason is that we didn’t want to rule out >extension of OSPFv2 completely. >> >> >> >> >> 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. >> >> I will clarify this. However, I don’t want to specify any assumption >about allocation. >> >> >> >> 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.xht >ml#ospfv2-parameters-5) >> - so perhaps you could simply say so or clarify for what are valid >> values. >> >> Is there an example of referencing an IANA directory? I could also >reference RFC 2823 and RFC 3101 directly. >> >> >> >> 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. >> >> Sure. We’ll do the same. >> >> >> >> 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. >> >> Ok - I need to hunt down this OSPF Wiki we talked about in Prague as >well. >> >> >> >> Nits: >> >> 6) In Sec 2, there's an "e.g., mapping server deployment". Could you >add >> a reference? This tells me nothing... >> >> Sure - it is the segment routing architecture document. >> >> >> >> 7) In Sec 2, In the packet format, could you clarify Opaque type = 7? >Same >> for on p.8 for opaque type = 8 ? >> >> Sure. >> >> >> 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 >> >> Sure. >> >> Thanks, >> Acee >> >> >> >> Regards, >> Alia >> > > >------------------------------------------------------------------------ >-------- > > >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> >
- [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)