BGP ACCEPT_OWN Community Attribute
RFC 7611

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

(Alia Atlas) Yes

Comment (2015-02-03 for -09)
No email
send info
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?

(Adrian Farrel) Yes

Comment (2015-01-22 for -09)
No email
send info
Please consider changing "This memo defines a new BGP community" to "This memo defines a new well-known BGP community"

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2015-02-05 for -09)
No email
send info
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

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-02-03 for -09)
No email
send info
- 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:-)

(Brian Haberman) No Objection

Comment (2015-02-03 for -09)
No email
send info
I agree with Alia's suggested text change.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-01-26 for -09)
No email
send info
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?

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-02-03 for -09)
No email
send info
I support Stephen's comment.

(Pete Resnick) No Objection

Comment (2015-02-04 for -09)
No email
send info
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.

(Martin Stiemerling) No Objection