For the Blackhole community can we just describe its purpose/usage and
just show the *:666 or *:999 as examples? I think the purpose and
function matter a lot more than what arbitrary number is used.
+1
Regards.
/Alex Saroyan
On 02/10/2015 11:09 AM, Rick Casarez wrote:
All,
For the Blackhole community can we just describe its purpose/usage and
just show the *:666 or *:999 as examples? I think the purpose and
function matter a lot more than what arbitrary number is used.
-------------------
Cheers, Rick
Experiences not things.
On Tue, Feb 10, 2015 at 1:31 AM, Alex Saroyan <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I think idea behind BCOP in comparison with BCP is that we
populate here the best practices which are "really used by
operators". kind of real life examples.
This is how I understood idea of BCOP introduced at first by Jan Zorz.
Thus, I think we should not start including all the possible
variations which are good for all the possible types of BGP speakers.
2. BGP Session Security - a mention of conformance with rfc5082 was
also presented, and it I think it makes sense to add, does everyone
agree? 2a. Along those lines is there agreement that the document
should have a section covering basic BGP security considerations?
Does anybody use or offer 5082 today, in practise?
I support Job Snijders' question - because if no Operator use this
feature, it should not be included. I've never seen this used
rather then in CCIE LAB.
Most prevalent blackhole community is ASN:666, so i'd drop the :999
reference.
Job: Some people are not happy with number 666 and many operators
use 999 in real life. Both 666 and 999 are widely used among
operators, so we can of course write that 666 is more widely used
then 999 but I'm not sure that we can insist on using 666 only.
3. Prefix Length Integrity - The idea of identifying a maximum prefix
lengths for both customers and ISPs to accept as well as a potential
for a better defined interpretation of Strict\Loose prefix handling.
ie. Loose = the /24(ipv4) and /48(ipv6). Strict = using the RIR
minimal allocation as the limit.
I can only speak for myself: if a customer registers up to a /30 as
route object, I'd accept the prefix. If the customer registers a /24 or
smaller, I'd accept up to a /24. Anything larger then a /24 I would not
propagate to peers or other customers.
Here I think, we should insist that every operator MUST at least
accept everything (of course properly registered) up to /24 and
/48. Preventing all ideas of accepting up to /23 or shorter.
Regards.
/Alex Saroyan
On 02/10/2015 09:30 AM, BARRY GREENE wrote:
On Feb 10, 2015, at 5:24 AM, Scott Morris <[email protected]
<mailto:[email protected]>> wrote:
I can incorporate them into the draft stuff I worked on.
Not for this draft, but for the next one, I’ll put together a
reference section from all the older “BGP BCP” materials. This
will go back to the ISP Workshop materials and work forward. I’ll
include all the NANOG tutorial/session pointers.
One other point, what about
https://tools.ietf.org/html/draft-ietf-opsec-bgp-security-07???
I think we should try some sort of alignment. If our goal is
“behavior change,” then we should ensure the two documents
provide the same guidance. Duplication is A-OK. We just reference
each other.
_______________________________________________
BCOP mailing list
[email protected] <mailto:[email protected]>
http://mailman.nanog.org/mailman/listinfo/bcop
_______________________________________________
BCOP mailing list
[email protected] <mailto:[email protected]>
http://mailman.nanog.org/mailman/listinfo/bcop
_______________________________________________
BCOP mailing list
[email protected]
http://mailman.nanog.org/mailman/listinfo/bcop
_______________________________________________
BCOP mailing list
[email protected]
http://mailman.nanog.org/mailman/listinfo/bcop
