Skip to main content

BGP ACCEPT_OWN Community Attribute
RFC 7611

Yes


No Objection

(Alissa Cooper)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Ted Lemon)

Note: This ballot was opened for revision 09 and is now closed.

(Adrian Farrel; former steering group member) Yes

Yes (2015-01-22 for -09)
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

Yes (2015-02-03 for -09)
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

No Objection (for -09)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2015-01-26 for -09)
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

No Objection (2015-02-05 for -09)
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

No Objection (2015-02-03 for -09)
I agree with Alia's suggested text change.

(Jari Arkko; former steering group member) No Objection

No Objection (for -09)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -09)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-02-03 for -09)
I support Stephen's comment.

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -09)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2015-02-04 for -09)
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

No Objection (for -09)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -09)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-02-03 for -09)
- 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

No Objection (for -09)