My comments on draft-ietf-grow-blackholing-02:
- If the only purpose of the draft is to standardize the RTBH
signaling community, wouldn't a better approach be to attempt to
update RFC5635?
- Standardizing the RTBH signaling community is insufficient, as the
party who wants to use it also needs to know where to signal:
"in-band" with all the other route announcements, or via the
dedicated ebgp-multihop session that some providers use? The last
time I checked, some providers do it one way, and some the other;
some customers prefer upstreams who do it one way, some the other.
Yes, if you are under attack, I'm sure it's annoying to have to locate
the RTBH community of each of your upstream providers. But I would
argue that it's critical for anyone using RTBH service from their
upstreams to know key aspects of each provider's RTBH implementation:
- in-band or ebgp-multihop?
- host routes only, or other ranges as well?
- does the provider require pre-arrangement?
- does the provider enforce a maximum duration of RTBH?
- what does the provider do with RTBH announcements on prefix-lengths
the provider says are out-of-scope? e.g. if a provider says RTBH
only on ipv4 /32 routes, yet the customer announces a /31 or a /24
with the RTBH community?
Bottom line, I feel that standardizing the RTBH signaling community
does not bring enough benefit, and it sets the stage for customer
confusion and disappointment: "I sent the BLACKHOLE community to
upstream-X and to upstream-Y, and I got different results. How come?"
Thanks.
Jay B.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
