Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 6368
Yes
(Ron Bonica)
(Stewart Bryant)
No Objection
(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Pete Resnick)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Wesley Eddy)
Note: This ballot was opened for revision 08 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2011-06-07)
Unknown
A rather well written document. Thank you.
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Stewart Bryant Former IESG member
Yes
Yes
()
Unknown
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2011-06-08)
Unknown
The Gen-ART Review by Suresh Krishnan on 7-Jun-2011 includes two suggestions for improvement. (1) The authors readily accepted the first suggestion. Please make sure the changes related to the first one make it into the document prior to publication. (2) The authors questioned the value of the second suggestion. My personal preference would be to include a very general statement the need for protection against memory exhaustion attacks in the security considerations section, but I will not demand one.
Sean Turner Former IESG member
No Objection
No Objection
(2011-06-09)
Unknown
These ought to be pretty easy to fix up. Most are about 2119 language usage. #1) elide the reference from the abstract #2) Section 4 contains the following: When a PE received route is imported into a VRF, its IGP metric, as far as BGP path selection is concerned, should be the metric to the remote PE address, expressed in terms of the service provider metric domain. r/should/SHOULD? #3) r/ATTR_SET is an optional transitive/ATTR_SET is an OPTIONAL transitive #4) Section 5 contains the following: It should contain the autonomous-system number of the customer network that originates the given set of attributes. r/should/SHOULD? #5) Section 5 contains the following: BGP speakers that support the extensions defined in this document must also support RFC4893 [RFC4893]. r/must/MUST? #6) Section 5 contains the following: When present it should be ignored by the receiving PE. r/should/SHOULD? #7) Section 7 contains the following: Otherwise, in the case of an autonomous- system number mismatch, the set of attributes to be associated with the route shall be constructed as follows: and When advertising the VRF route to an Exterior BGP peer, a PE router shall apply steps 1 to 4 defined above and subsequently prepend its own autonomous-system number to the AS_PATH attribute. r/shall/SHALL ? #8) Section 8 contains the following: It is recommend that different VRFs of the same VPN (i.e. in different PE routers) which are configured with iBGP PE-CE peering sessions use different Route Distinguisher values. r/recommended/RECOMMENDED ? also r/Route Distinguisher values/Route Distinguisher (RD) values #9) In Section 8, expand NLRI
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2011-06-08)
Unknown
(1) Some acronyms aren't expanded - VRF was the one that got me as well as ASBR. I guess implementers of this would know but just in case. (2) The diagram at the start of section 4 could be clearer. I found it confusing anyway. (3) last line of p8 - is that "should" or "SHOULD"? When would it be ok to not contain the ASN of the customer? (4) s/VPN network/VPN/ (Sorry, pet peeve of mine:-) (5) When is it ok to include the NEXT_HOP attribute in an ATTR_SET? Text says SHOULD NOT which implies there are cases when its the right thing to do - documenting (some of) those would be better.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown