Hi Randy,
one more: Can you please replace "Invalid" by "Not Valid", because
this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17.
Thanks
matthias
On Thu, 16 Jun 2016, Matthias Waehlisch wrote:
> 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 <sa...@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 <morr...@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.waehli...@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
