[karp] RtgDir review: draft-ietf-karp-ospf-analysis-05

Russ White <russw@riw.us> Wed, 17 October 2012 21:01 UTC

Return-Path: <russw@riw.us>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6326021F8578; Wed, 17 Oct 2012 14:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWXVXG1xvtpc; Wed, 17 Oct 2012 14:01:48 -0700 (PDT)
Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 03EC021F846A; Wed, 17 Oct 2012 14:01:48 -0700 (PDT)
Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.130]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <russw@riw.us>) id 1TOakN-0005oj-30; Wed, 17 Oct 2012 14:01:47 -0700
Message-ID: <507F1CC1.7070301@riw.us>
Date: Wed, 17 Oct 2012 17:01:53 -0400
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: rtg-ads@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
Cc: rtg-dir@ietf.org, karp@ietf.org, draft-ietf-karp-ospf-analysis.all@tools.ietf.org
Subject: [karp] RtgDir review: draft-ietf-karp-ospf-analysis-05
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2012 21:01:54 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all

routing or routing-related drafts as they pass through IETF last call
and IESG review, and sometimes on special request.

The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing

Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them

along with any other IETF Last Call comments that you receive, and
strive to resolve them through discussion or by

updating the draft.

Document: draft-ietf-karp-ospf-analysis-05
Reviewer: Russ White
Review Date: 17 October 2012
IETF LC End Date:
Intended Status: Informational

Summary:

I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

This draft is well written and formatted, and serves a useful need
within the intersection of security and routing

protocols. In general, the draft is ready for publication, but I did
have one or two questions or areas where things

might be clarified in order to make the final result more readable.

Major Issues:

None

Minor Issues:

The OSPFv2 replay mechanism does not handle packet priorities as
described. If packets are processed out-of-order, then if the
sequence number increases, packets processed later will be discarded.

I'm not certain I understand this --packet processing priority within
the ospf process, or for inbound queue processing?

Or for processing packets in the order in which they are recieved? It
might be useful to explain which one is being

discussed.

==
There is another serious problem with the OSPFv3 security: rather
than being integrated into OSPF, it is based on IPsec. In practice,
this has lead to deployment problems.

I assume this means in terms of deployment difficulty --I'd just like to
make certain the WG agreed with this assessment

overall (while I tend to agree, I remember there being some pushback on
this type of statement in the past).

Nits:

Single space after periods throughout



==

Russ