OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol
draft-ietf-l3vpn-ospfv3-pece-11
Yes
(Stewart Bryant)
No Objection
(Gonzalo Camarillo)
(Pete Resnick)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Wesley Eddy)
No Record
(Cullen Jennings)
(Lars Eggert)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Ross Callon)
Note: This ballot was opened for revision 11 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2009-12-15)
Unknown
[BGP-EXTCOMM-IPV6] should be [RFC5701] and should probably be a Normative Reference.
Stewart Bryant Former IESG member
Yes
Yes
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2011-12-14)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2011-12-14)
Unknown
+1 to comments from Fred Baker and Dan Romascanu
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
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2011-12-13)
Unknown
- 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 IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Record
No Record
()
Unknown
Lars Eggert Former IESG member
No Record
No Record
()
Unknown
Lisa Dusseault Former IESG member
No Record
No Record
()
Unknown
Magnus Westerlund Former IESG member
No Record
No Record
()
Unknown
Pasi Eronen Former IESG member
No Record
No Record
()
Unknown
Ross Callon Former IESG member
No Record
No Record
()
Unknown