Hi, On Tue, Aug 09, 2016 at 04:50:58PM +0100, Stephen Farrell wrote: > Ok - I assume that means that being able to accept a blackholed /32 > doesn't therefore mean having to accept other BGP announcements for > /32's without any additional controls. Would it be sensible to say > that implementers MUST/SHOULD allow treating blackholing differently > in that respect? (e.g. to keep some different configured limits for > the length of prefix they accept for blackholes vs. other BGP stuff?)
I think this is implicit by the statement that there must be a covering
prefix permitted by routing policy - so the assumption is "the blackhole
can be more specific".
All existing deployments I know do it that way - that is, for regular
traffic, prefixes are permitted as documented (like: 192.0.2.0/24 is
accepted, and no more specifics) while blackhole-tagged prefixes
go up to /32 ("if blackhole-community present, accept 192.0.2.0/24../32").
I'm not sure if we need to spell this out - it's not something this draft
is changing.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
