On Fri, Jun 26, 2015 at 06:27:23PM +0000, Thomas King wrote:
> > Another remark, should you decide to rename BLACKHOLEIXP to just
> > BLACKHOLE, you might want to replace the references to "IXP" throughout
> > the document and make it more general.
>
> I am not sure if a more general approach (= ISP / transit environment)
> makes lots of sense given RFC 3882.
Can you elaborate what the conceptual difference would be between a
transit network and an IXP Route Server in this context? RFC 3882 does
not define any well known community.
Whether packets are discarded inside the IXP fabric or somewhere in the
Transit provider's fabric^Wmagic.. I don't see much of a difference.
In section 2:
"The semantics of this attribute is to allow an IXP to interpret the
presence of this community as an advisory qualification to drop any
traffic being sent towards this prefix."
One could consider changing it to:
"The semantics of this attribute is to allow a network to interpret
the presence of this community as an advisory qualification to drop
any traffic being sent towards this prefix."
(of course the rest of the document would also need some updating)
For years IP networks have offered blackhole services to their
customers, much like some IXPs are now starting to do. One could argue
that a standardized blackhole community is beneficial, in the spirit of
the NOPEER community. Today NTT uses 2914:666 while Level3 uses
3356:9999, if multi-homed networks only need to remember 1 community,
that might be easier.
IXPs offer the blackholing (1) either themselves inside the fabric, (2)
or through a construct where IXPs ask participants to implement routing
policy honoring a 'blackhole' community, or (3) asking participants to
at least accept the route with a blackhole-next-hop of sorts.
Scenario (2) is no different then the offering of today's blackhole
community by most IP networks.
Kind regards,
Job
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
