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

From: Russ White <[email-masked]>
Date: Wed, 17 Oct 2012 17:01:53 -0400

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