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
>>
>