Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

Hi,

  I read v09. No objections only minor comments:

line 102: BGPsec need*s* *to* be spoken only

line 104: s/by small edge routers/by resource constrained edge routers/

line 119: *see* [RFC4271]

line 159: s/..../etc./

lines 200-206 seem redudant to lines 208-213

line 202 s/smallish/resource constrained/

line 215: I don't know where the 84% comes from, I suppose it's just a 
more or less arbitrary illustration of "vast majority". I would remove 
the number.

line 234: I would be more explicit: "How this is used in routing is up 
to the operator's local policy, similar to origin validation [RFC6811]."

lines 243-250: This paragraph confused me. What about:

Operators should be aware that controlling Invalid announcements by 
local preference might be delusive. Local preference affects only routes 
to the same set of destinations. Consider having a Valid announcement 
from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 
10.0.66.0/24 from neighbor I. If the local policy on a router is 
configured to accept Invalid announcements, then both routes will be 
installed, no matter of the value of local preference.

(Btw, I suppose that routes to .666 will be discarded anyway ;)

line 252: It sounds that only edge routers are allowed to speak BGPsec. 
I would weaken and say "Validation of signed paths is usually deployed 
at the eBGP edge."

line 292: s/BGPSEC_Path/BGPsec_Path/

lines 288-295:  The paragraph seems to mix transparent operation and the 
question of validation. What about:

A route server is usually 'transparent'. To operate transparently in an 
environment in which the route server connects BGPsec-enabled peers, the 
route server needs to run BGPsec as well. This implies that the route 
server creates signatures per client including its own AS in the 
BGPsec_Path and the target ASes. However, increasing the AS hop count 
reduces the likelihood of best path selection. See 2.2.2 of 
[I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route 
server uses pCount of zero to not increase the effective AS hop count.

Furthermore, a BGPsec-aware route server needs to validate the incoming 
BGPsec_Path but should not drop invalids. In case the client speaks 
BGPsec the route server should just forward updates to clients which 
then validate . In case the client does not speak BGPsec, the route 
server reconstructs the AS_PATH and may signal the validation outcome 
using communities.

line 300: s/Routers should default to this knob disallowing pCount 0./Routers should disallow pCount 0 by default./

line 346: I would rephrase: "Operators should deploy servers that 
provide time service, such as [RFC5905], to client routers."

Cheers
  matthias

On Wed, 15 Jun 2016, Sandra Murphy wrote:

> It is a short document.  The sentences are not complicated.  It reads quickly.
> 
> There’s been little/no wg comment on this, certainly no controversy, over the lifetime of the draft.
> 
> But still.
> 
> Please.  Pretty please.  Pretty please with sugar on top.  Pretty please with a cherry on top.
> 
> Could we get some feedback that this document is ready for publication?
> 
> —Sandy, speaking as one of the wg co-chairs
> 
> 
> On Jun 8, 2016, at 10:19 PM, Sandra Murphy <sandy@tislabs.com> wrote:
> 
> > No responses at all.
> > 
> > Come on folks.  It’s a short document, like Chris says.
> > 
> > You should be able to read and comment without much trouble.
> > 
> > —Sandy, speaking as one of the wg co-chairs
> > 
> > On Jun 1, 2016, at 2:52 PM, Chris Morrow <morrowc@ops-netman.net> wrote:
> > 
> >> 
> >> Howdy WG folks,
> >> Please take this note as the start of the 2wk WGLC period for:
> >> <https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-07>
> >> 
> >> Abstract:
> >> "Deployment of the BGPsec architecture and protocols has many
> >>  operational considerations.  This document attempts to collect and
> >>  present the most critical and universal.  It is expected to evolve as
> >>  BGPsec is formalized and initially deployed."
> >> 
> >> This is a relatively short document, 8 pages, full of wonder and
> >> excitement! I hope that the wg members have read it (it's been through
> >> 8+ revisions) and that they will re-read it quickly, provide comments
> >> as appropriate and ideas on preparedness for publication or not.
> >> 
> >> 
> >> Thanks for you time and attention to this matter,
> >> 
> >> -Chris
> >> co-chair-persona
> >> 
> >> _______________________________________________
> >> sidr mailing list
> >> sidr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sidr
> > 
> 
> 

-- 
Dr. Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:m.waehlisch@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net