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

[Randy Bush <[e-mail]>]

>   I read v09. No objections only minor comments:

i hacked in many of these changes, though i think most did not really
change anything other than an alternate way of saying the same thing.
but i just do not want to see this go on an on interminably.  and at
least you reviewed it.  thanks!

randy

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