BGP ACCEPT_OWN Community Attribute
RFC 7611
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
(Adrian Farrel; former steering group member) Yes
Please consider changing "This memo defines a new BGP community" to "This memo defines a new well-known BGP community"
(Alia Atlas; former steering group member) Yes
In Sec 2,2, it says: "This implies that when propagating routes into a VRF, the ACCEPT_OWN community should not be propagated. Likewise, if a route carrying the ACCEPT_OWN community is received in an address family which does not allow the source VRF to be looked up, the ACCEPT_OWN community MUST be discarded." In the first sentence above, it seems like the "should not" should be either "SHOULD NOT" or "MUST NOT". Is there a reason that the text is descriptive instead of normative?
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
Nothing blocking here, but some things to please consider (and chat with me if you think it's needed): Please expand "VRF" and "PE" on first use. -- Section 2.1 -- A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value matches that of the receiving speaker if all of the following are true: Just checking here: 1. The "MAY" means that even if all the following are true, the router might still not accept the route -- it's optional. Is that what's intended? 2. This text says nothing about what happens if *not* all of the following are true. A router might still accept the route (or not). Is that what's intended? Or is a "MUST NOT accept" meant to be implied in that case? A route MUST never be accepted back into its source VRF, even if it carries one or more Route Targets (RTs) which match that VRF. I think "MUST never be accepted" is a bit awkward, because one immediately thinks of "MUST" as a positive command. I suggest "A route MUST NOT ever be accepted...." -- Appendix A -- The title says "Local Extranet Application (non-informative)". Do you mean "non-normative" here?
(Benoît Claise; former steering group member) (was Discuss) No Objection
Clearing my DISCUSS on the basis that the following text is added as a RFC editor note, as discussed with Adrian and Ron Bonica: OLD: ACCEPT_OWN handling SHOULD be controlled by configuration, and SHOULD default to being disabled. NEW: ACCEPT_OWN handling SHOULD be controlled by configuration, and if controlled by configuration it MUST default to being disabled
(Brian Haberman; former steering group member) No Objection
I agree with Alia's suggested text change.
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
I support Stephen's comment.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
In the ballot: Opposition to the proposal was initially expressed by one contributor, but there was good support for adoption and no particular follow-up from that contributor. I'm glad someone wrote it down, but it's not exactly confidence inspiring. Was this just random opposition without explanation, or did the person have a point and it got addressed to the chairs' satisfaction, or did something get dropped? I expect it's that the concern was addressed reasonably, but the above doesn't exactly say that.
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- section 6: I think I buy the argument that there are no new security issues here but that's only true I think if the security issues with route reflectors are somewhere (and if those cover cases where crypto is not used to enforce the "P" in VPN). Wouldn't a reference to something like that be good here? - I like non-informative appendices:-)
(Ted Lemon; former steering group member) No Objection