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]> 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]> 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 [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
