Moin,
> These are two points, though related... and we're running into this
> just today (sending GSHUT + 3x prepend to IXP to drain our traffic
> before a planned outage, and peers just ignoring the GSHUT and
> overriding the prepend with LPREF...) - so yes, let's make this
> happen :-)
Incidentally somebody i know also just had some violent fantasies,
involving flapping 50G to people who do not honor GSHUT. Added a
ticket.
> This is a bit of "my network, my rules" thing - this is all very
> strongly recommended, so SHOULD, but there might be good reason why a
> particular recommendation can not be followed ("something mumble
> mumble vendor mumble mumble not working").
I agree; Yet, the question is whether framing it 'MUST to follow best
practices' makes the trade-off "Well, you can do that differently, but
then you do not follow best practices in that specific case, despite
having good reasons" more clear;
In general, it might be good to add a statement on this trade-off being
necessary and in the judgment of the individual operator might be good
(regardless of whether it ends up SHOULD or MUST in the main text).
Added a ticket.
>
> Having been bitten by a vendor that honours GSHUT on iBGP (and lowers
> local-pref to 0), which causes persistent loops when other vendors in
> the same iBGP mesh do not do this, indeed, a few words on "SHOULD not
> mess with priorities on iBGP" would be good - though less an "BGP
> security" topic, more a "robust operations" thing.
Not to sure about this, as this is vendor behavior, which iirc is out-
of-scope for the doc (despite this making sense). Would be nice to hear
some more opinions on that.
Might also make sense to add something more on iBGP re: MEDs and
filtering when using RRs, referencing RFC7964.
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M [email protected]
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
