OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol
draft-ietf-l3vpn-ospfv3-pece-11
Yes
No Objection
No Record
Note: This ballot was opened for revision 11 and is now closed.
Lars Eggert No Record
(Adrian Farrel; former steering group member) Yes
[BGP-EXTCOMM-IPV6] should be [RFC5701] and should probably be a Normative Reference.
(Stewart Bryant; former steering group member) Yes
(Dan Romascanu; former steering group member) No Objection
Fred Baker made in his OPS-DIR review a couple of comments which are not show stoppers but deserve being answered and clarified if necessary in the text: 1. The introduction mentions the use of OSPFv2 for IPv4 and OSPFv3 for IPv6. With the advent of OSPFv3 address families, mentioned in section 6, it is possible to use OSPFv3 for IPv4, enabling one protocol and one configuration to be used for both network layer protocols. I would expect that this might be a useful thing to comment on in the introduction. 2. The one question I was left asking was why the document mentioned MPLS in 20 places but did nothing with MPLS other than mention that it was used in BGP/MPLS VPNs. The routing technology could just as easily be used on any other PE-CE link; the point is that it is between an OSPFv3 instance in the PE and a correspondent on the CE router, enabling a customer to communicate with an upstream in a manner that enabled the upstream to trust routing information without the customer needing to obtain an AS number and operate a BGP configuration. That's not an impediment; the document only chose to specify that configuration. But the narrowness of specification left me puzzled.
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
+1 to comments from Fred Baker and Dan Romascanu
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- Who's the document shepherd? Tracker note says Ben, iesg writeup says Danny. Probably a typo somewhere or a change, but might be worth fixing. - The abstract is confusing. It says "We had BGP/MPLS for IPv4; then we added IPv6; then we added OSPFv2 and now in this document, we add OSPFv3." Telling the reader about IPv4/IPv6 just seems distracting here. - NLRI & NSSA not expanded on 1st use. - Is it safe to use a NULL domain ID? If I do that then an incoming message can easily be confusing? - Section 7 refers to rfc 4659 section 11 and 4577 section 6. 4659 section 11 refers to 2545 section 5 and 4364 section 13. 4577 refers to 4364 and 4365. 2545 says "nothing new here." 4364 is updated by 4577, 4684 and 5462. 4577 says "cryptographic authentication" SHOULD be used and MUST be implemented but doesn't say what "cryptographic authentication" really means. I stopped following the breadcrumbs at that point;-) Can't we do this better and simpler?
(Wesley Eddy; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Record
(Lisa Dusseault; former steering group member) No Record
(Magnus Westerlund; former steering group member) No Record
(Pasi Eronen; former steering group member) No Record
(Ross Callon; former steering group member) No Record