Thanks! No further comments from my side. Looing forward to publication.
Cheers matthias On Fri, 24 Jun 2016, Randy Bush wrote: > > 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." > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
