On 09/08/16 17:04, Gert Doering wrote:
> 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.(Noting that this was an aside that I don't consider blocking...) I think one could argue that this draft is changing that as it's here that we're defining this community. And I'd say it would be useful to call it out too, if there's really no sensible way to implement this without such an additional configuration. Cheers, S. > > Gert Doering > -- NetMaster >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
