OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
draft-ietf-l3vpn-ospf-2547-06

!! Missing Reference for citation: [OSPF-DNbit]
  P006 L054:    [OSPF-DNbit] in the LSA Options field MUST be set.  This is used to
  P007 L022:    distributes the route in a type 5 LSA.  The DN bit [OSPF-DNbit] MUST

Possibly the citation should be [OSPF-DN] ??

IS there a strange "80" at the right top side of the figure on page 9?

------------------

additional comment from OPSDIR review (by Pekka)

Security Considerations discussion seems inadequate.  It does not 
mention at all the considerations about running an IGP like OSPF 
between two administrative domains, i.e., across a trust boundary, 
against the typical security design of such a protocol. (This is one 
reason why we, for example, withdrew from using anything except BGP 
and static routing towards customers like 5 years ago.)

The first paragraph of Section 4.1 already mentions some key problems 
in this area, that is, somehow ensuring that the particular CE cannot 
affect any routing decisions which is should not have any business 
dealing with, but this needs to be also discussed at security 
considerations.  Further, having to expose OSPF to the untrusted CEs 
should be discussed -- the main threats being 1) the potential for 
bugs and misconfigurations etc. which would allow the CE to leak some 
routing information to the main/other VPNs' "contexts" -- e.g., 
injecting host routes for hijacking traffic, and 2) having to expose 
the OSPF protocol interface to the CEs (providing an attack vector the 
first threat)

I think these issues are probably adequately addressed in the spec, 
and probably also in the implementations, but as said, the threat 
potential should be spelled out.

As an afterthought, you might consider s/must be capable of 
running/MUST run/ in section 4.1:

    [VPN] defines the notion of a Per-Site Routing and Forwarding Table,
    or VRF. A PE router must be capable of running multiple instances of
    OSPF, where each instance is associated with a particular VRF.
    [...]

.. because otherwise the security design of the spec is severely 
breached.

Reviewed by Lucy Lynch, Gen-ART
Her review:

This draft is basically ready for publication, but has nits that should
be fixed before publication.

Just a comment here, I find it mildly disconcerting that this document
has seen no real changes from v.00 -> v.01 -> v.02 and very little
comment on the l3vpn mailing list. Is this just an exercise in covering
all the bases, or is there really a need for OSPF support at the CE?
The use of the term "sham link" is also a bit odd, although accurate.
If "Sham links SHOULD be treated by OSPF as OSPF Demand Circuits" maybe
they are really VODCs?

ID tracker already reflects most of the nits and the IANA related issues

  Please spell out the first use of ABR.

  In section 4.1: s|Import/export to/from|Import from and export to|

  This is an add series of section titles:
  >
  >  4.2.   Details
  >  4.2.1. General
  >
  Perhaps the section title for 4.2.1 should simply be dropped, since
  there is no text in section 4.2.

  In section 4.2.2 (OSPF Domain Identifier Extended Communities attribute):
    s/UNLESS/unless/
    s/is NOT omitted/is present/

  In section 4.2.3.2: s/IF/If/

Please cite RFC 2119 as a normative reference.