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

-------- Original Message --------
Subject: Re: Implementaton report:draft-ietf-l3vpn-ospf-2547bis
Date: Mon, 20 Feb 2006 10:05:40 -0500
From: Eric Rosen
Reply-To: erosen@cisco.com
To: Mark Townsley


In  the  -06  version  of  the  draft,  posted  last  week,  the  sham  link
auto-configuration stuff was all removed, per Alex's instructions. 

I  believe  that  this  version  of  the  draft  and  this  version  of  the
implementation report are what Alex asked for last week.

New Implementation Report (for -06)

There are at least two independent implementations of draft-ietf-l3vpn-ospf-
2547bis, one  by Cisco and one  by Juniper.  Below  is the list of  the main
features of the draft, along with information as to whether the features are
supported by the implementations.

All  of the  procedures  which  are supported  by  both implementations  are
believed  to be  interoperable.  However, these  implementations have  been
deployed for  so long  that it  isn't really possible  to cite  the specific
interoperability testing  that was  done.  At the  current time, we  are not
aware of any interoperability problems.

1. Separate and independent instance of OSPF for each VPN.

  Cisco: yes
  Juniper: yes

2. Proper handling of Domain Identifiers.  The use of these is optional, but
  an implementation which  doesn't use them must still  properly handle the
  reception of routes which carry domain identifiers.

  Sub-features:

  a. Ability  to assign a Domain  Identifier to each OSPF  instance, and to
      carry  it  in  the  OSPF  Domain  Identifier  Extended  Communities
      attribute.  This must  be configurable  per OSPF  instance,  and must
      default to NULL.

      Cisco: yes
      Juniper: yes

  b. Ability  to  properly  encode  the  Domain  Identifier  as  a  Domain
      Identifier Extended Communities attribute. 

      Cisco: yes
      Juniper: yes

  c. Interpretation  of Communities  0005, 0105, 0205,  and 8005  as Domain
      Identifier Extended Communities.

      Cisco: yes
      Juniper: yes

  d. Proper handling  of received  Domain Identifier  Extended Communities
      attributes, including  the specified rules for equality  of two domain
      identifiers, and  using Domain Identifier to help  determine whether a
      particular route is an external route.

      Cisco: yes
      Juniper: yes

  e. Recognition  that  the  absence  of  a  Domain  Identifier  Extended
      communities attribute  is functionally identical to the  carrying of a
      NULL attribute.

      Cisco: yes
      Juniper: yes


3. The ability to assign any link to any area, including area 0.

  Cisco: yes
  Juniper: yes

4. The PE functions as ABR for any non-0 area to which it is attached.

  Cisco: yes
  Juniper: yes

5. The OSPF  decision process installs best OSPF-distributed  route into the
  VRF.

  Cisco: yes
  Juniper: yes

6. Translation  of OSPF  routes  into BGP-distributed  VPN-IPv4 routes  with
  following attributes: 

  * Route Type Extended Communities attribute
  * Domain Identifier (optional)
  * OSPF metric carried in MED as per specification

  Cisco: Yes
  Juniper: Yes

7. Proper setting and processing of the DN bit

  Cisco: yes
  Juniper: yes

8. Proper  setting and  processing  of  the OSPF  route  tag, including  the
  default value.

  Cisco: yes
  Juniper: yes

9. Proper procedures for importing BGP routes into the VRF:

    a. Eligibility for import based on RT
    b. BGP decision process selects best BGP route
    c. Preference for OSPF-distributed route over BGP-distributed route.

    Cisco: yes
    Juniper: yes

10. BGP routes advertised  by OSPF if and only if they  are installed in the
    VRF.

    Cisco: yes
    Juniper: yes

11. Proper procedures for translating  BGP-distributed OSPF routes into OSPF
    routes for readvertisement into OSPF. 

    a. Proper handling of BGP-distributed routes which were originally intra-
      area. 

    Cisco: yes
    Juniper: yes

    b. Proper handling of BGP-distribute routes which were originally inter-
      area.

    Cisco: yes
    Juniper: yes

    c. Proper  handling of BGP-distribute  routes which were  originally AS-
      external.

    Cisco: yes
    Juniper: yes

    d. Proper handling of BGP-distribute routes which were originally NSSA..

    Cisco: yes
    Juniper: yes

12. Sham links (optional)

    a. Treated as demand circuits (optional)

    Cisco: yes
    Juniper: yes

    b. Sham Link Endpoint Address advertised by BGP, but NOT by OSPF.

    Cisco: yes
    Juniper: yes

    c. Configurable metric for sham link

    Cisco: yes
    Juniper: yes

    d. Proper procedures  for sending OSPF messages on  sham link, including
      the default intervals for control messages.

    Cisco: yes
    Juniper: yes


    e. Proper procedures for forwarding data on sham links.

    Cisco: yes
    Juniper: yes

-------- Original Message --------
Subject: Implementation report for draft-ietf-l3vpn-ospf-2547
Date: Fri, 13 Jan 2006 12:48:06 -0500
From: Eric Rosen
Reply-To: erosen@cisco.com
To: Ronald Bonica , Ross Callon ,        Rick Wilder , Mark Townsley ,        Alex Zinin

I hope  this is  the information which  is needed.  I'm not sure  where I'm
supposed to send it, so ...

There are at least two independent implementations of draft-ietf-l3vpn-ospf-
2547bis, one  by Cisco and one  by Juniper.  Below  is the list of  the main
features of the draft, along with information as to whether the features are
supported by the implementations.

All  of the  procedures  which  are supported  by  both implementations  are
believed  to be  interoperable.  However, these  implementations have  been
deployed for  so long  that it  isn't really possible  to cite  the specific
interoperability testing  that was  done.  At the  current time, we  are not
aware of any interoperability problems.

1. Separate and independent instance of OSPF for each VPN.

  Cisco: yes
  Juniper: yes

2. Ability to  have more  than one  OSPF instance per  VRF, with  one being
  primary (optional).

  Cisco: yes
  Juniper: no

3. Proper handling of Domain Identifiers.  The use of these is optional, but
  an implementation which  doesn't use them must still  properly handle the
  reception of routes which carry domain identifiers.

  Sub-features:

  a. Ability  to assign a Domain  Identifier to each OSPF  instance, and to
      carry  it  in  the  OSPF  Domain  Identifier  Extended  Communities
      attribute.  This must  be configurable  per OSPF  instance,  and must
      default to NULL.

      Cisco: yes
      Juniper: yes

  b. If there can be multiple OSPF instances per VRF, proper handling
      of the "primary" domain identifier.

      Cisco: yes
      Juniper: N/A

  c. Ability  to  properly  encode  the  Domain  Identifier  as  a  Domain
      Identifier Extended Communities attribute. 

      Cisco: yes
      Juniper: yes

  d. Interpretation  of Communities  0005, 0105, 0205,  and 8005  as Domain
      Identifier Extended Communities.

      Cisco: yes
      Juniper: yes

  e. Proper handling  of received  Domain Identifier  Extended Communities
      attributes, including  the specified rules for equality  of two domain
      identifiers, and  using Domain Identifier to help  determine whether a
      particular route is an external route.

      Cisco: yes
      Juniper: yes

  f. Recognition  that  the  absence  of  a  Domain  Identifier  Extended
      communities attribute  is functionally identical to the  carrying of a
      NULL attribute.

      Cisco: yes
      Juniper: yes


4. The ability to assign any link to any area, including area 0.

  Cisco: yes
  Juniper: yes

5. The PE functions as ABR for any non-0 area to which it is attached.

  Cisco: yes
  Juniper: yes

6. The OSPF  decision process installs best OSPF-distributed  route into the
  VRF.

  Cisco: yes
  Juniper: yes

7. Translation  of OSPF  routes  into BGP-distributed  VPN-IPv4 routes  with
  following attributes: 

  * Route Type Extended Communities attribute
  * Domain Identifier (optional)
  * OSPF metric carried in MED as per specification

  Cisco: Yes
  Juniper: Yes

8. Proper setting and processing of the DN bit

  Cisco: yes
  Juniper: yes

9. Proper  setting and  processing  of  the OSPF  route  tag, including  the
  default value.

  Cisco: yes
  Juniper: yes

10. Proper procedures for importing BGP routes into the VRF:

    a. Eligibility for import based on RT
    b. BGP decision process selects best BGP route
    c. Preference for OSPF-distributed route over BGP-distributed route.

    Cisco: yes
    Juniper: yes

11. BGP routes advertised  by OSPF if and only if they  are installed in the
    VRF.

    Cisco: yes
    Juniper: yes

12. Proper procedures for translating  BGP-distributed OSPF routes into OSPF
    routes for readvertisement into OSPF. 

    a. Proper handling of BGP-distribute routes which were originally intra-
      area. 

    Cisco: yes
    Juniper: yes

    b. Proper handling of BGP-distribute routes which were originally inter-
      area.

    Cisco: yes
    Juniper: yes

    c. Proper  handling of BGP-distribute  routes which were  originally AS-
      external.

    Cisco: yes
    Juniper: yes

    d. Proper handling of BGP-distribute routes which were originally NSSA..

    Cisco: yes
    Juniper: yes

13. Sham links (optional)

    a. Treated as demand circuits (optional)

    Cisco: yes
    Juniper: yes

    b. Use of Sham Link Endpoint Address Route Type (optional)

    Cisco: no
    Juniper: no

    c. Sham Link Endpoint Address advertised by BGP, but NOT by OSPF.

    Cisco: yes
    Juniper: yes

    d. Sham links optionally auto-configurable, with default to manual
      config

    Cisco: no
    Juniper: no

    e. Configurable metric for sham link

    Cisco: yes
    Juniper: yes

    f. Proper procedures  for sending OSPF messages on  sham link, including
      the default intervals for control messages.

    Cisco: yes
    Juniper: yes


    g. Proper procedures for forwarding data on sham links.

    Cisco: yes
    Juniper: yes

-------- Original Message --------
Subject: Meeting in Paris re review of draft-ietf-l3vpn-ospf-2547?
Date: Wed, 13 Jul 2005 12:38:08 -0700
From: Alex Zinin
Reply-To: Alex Zinin
To: Acee Lindem , Rohit Dube
CC: Mark Townsley , Ross Callon , Ronald Bonica , Rick Wilder , Eric Rosen , Bill Fenner
References: Your message of Mon, 13 Jun 2005 16:41:25 -0700. <211461640.20050613164125@psg.com> <200507131900.j6DJ0Xk6013875@rtp-core-1.cisco.com>


Acee, Rohit, folks-

As you guys know, Eric and I have gone through a few rounds of review for
this document and it has changed substantially as a result.

Eric should have another rev ready right after Paris, and I would like to
bring this document to OSPF for review. I suggest that we (OSPF and L3VPN
chairs, Eric, ADs if necessary) meet in Paris for 30 minutes to talk over
the review process, potential concerns, what's expected, etc.

Please send your time constrains.

Thank you.

--
Alex

[Note]: 'Waiting on new rev from Eric based on discussions with Alex and others. Proposed meeting in Paris may not happen as Eric will not be attending. OSPF WG signoff needed as well.
' added by Mark Townsley

[Ballot discuss]
> 4.1. Overview

>    Every PE attached to a particular OSPF network MUST function as an
>    OSPF area 0 router.

What does this mean, really? Does it mean that all interfaces should
be treated as belonging to area 0? Hopefully not. That it is a backbone-
connected ABR? If so, in what cases, in particular?
This statement is rather confusing.

>  This allows it to distribute inter-area routes to
>    the CE via Type 3 LSAs.  The CE router might or might not be an area
>    0 router, and the PE/CE link might or might not be an area 0 link.
 
> 4.2. Details
>
> 4.2.1. General
>
>    If a PE and a CE are communicating via OSPF, the PE MUST create, and
>    MUST flood to the CE, a type 1 LSA advertising its link to the CE.
>    The PE MUST have an OSPF router id which is valid (i.e., unique)
>    within the OSPF domain. The PE MUST also be configured to know which
>    OSPF area the link is in.

What is the point of specifying this? "Communicate via OSPF" implies it all.

>    Whether or not the PE-CE link is an area 0 link, the PE MUST function
>    as an OSPF area 0 router.

Same question as above.

>  That is, the link state topology from a
>    site will NOT be passed along by the PE.

Not sassed along where? What if the PE has a Sham Link with another PE?

>    Each OSPF domain MUST be associated with a Domain Identifier.  This
>    MUST be configurable, and the default value (if none is configured)
>    SHOULD be NULL.  More precisely, each VRF associated with an OSPF
>    instance will either be configured with one or more Domain
>    Identifiers, or else will use NULL as its Domain Identifier.

if > 1, does it mean there's more than one OSPF instance associated?

>    If a particular OSPF domain has the NULL Domain Identifier, care must
>    be taken to avoid having routes from that OSPF domain and routes from
>    another OSPF domain imported into the same VRF.

why?

The OSPF Domain ID notion is used, the rules are given, however, the concept is
not explained. I.e, is the goal to be able to tell whether it should look like
one OSPF domain to the customer or multiple? Please provide some description.

>    The value of the VPN Route Tag is arbitrary, but must be distinct
>    from any OSPF Route Tag being used within the OSPF domain.  Its value
>    MUST therefore be configurable.  If the Autonomous System number is
>    two bytes long, the default value SHOULD be an automatically computed
>    tag based on the Autonomous System number of the VPN backbone:

which "the Autonomous System" is meant here?

> 4.2.2. Handling LSAs from the CE
>
>    This section specifies the way in which a PE router handles the OSPF
>    LSAs it receives from a CE router.
>
>    When a PE router receives, from a CE router, any LSA with the DN bit
>    [OSPF-DN] set, the information from that LSA MUST NOT be used by the
>    SPF ("Shortest Path First") computation.  If a Type 5 LSA is received
>    from the CE, and if it has an OSPF route tag value equal to the VPN
>    Route Tag (see section 4.2.1), then the information from that LSA
>    MUST NOT be used by the SPF computation.

Strictly speaking, type-3's and type-5s are not part of "SPF" per se.
a more generic term like "route calculation" would be better.

>    Otherwise, the PE must examine the corresponding VRF. For every

Does this mean the VRF's routing table?

>    address prefix which appears there, the PE must create a VPN-IPv4
>    route in BGP.

Should that rather be "for each route installed by the corresponding OSPF
process"? Otherwise, one could pick up static routes, for example.

>  Each such route will have some of the following
>    Extended Community attributes:

>      - OSPF Route Type Extended Communities Attribute. This attribute
>        MUST be present.  It is encoded with a two-byte type field, and
>        its type is 0306. To ensure backwards compatibility, the type
>        8000 SHOULD be accepted as well, and treated as if it were type
>        0306.  The remaining six bytes of the Attribute are encodes as
>        follows:

and is it left as a reverse-engineering exercise for the reader to figure out
the exact order of these fields?

>          * OSPF Route Type: 1 byte, encoded as follows:
>
>              ** 1 or 2 for intra-area routes (depending on whether the
>                route came from a type 1 or a type 2 LSA -- however this
>                difference is not significant to the procedures
>                specified herein)
>
>              ** 3 for summary routes

this should be "inter-area" routes

>              ** 5 for external routes (area number must be 0)
>
>              ** 7 for NSSA routes.

Processing of NSSA routes hasn't been defined in this spec, btw.

>      - OSPF Router Id Extended Communities Attribute.  This OPTIONAL
>        attribute specifies the OSPF Router Id of the system that is
>        identified in the BGP Next Hop attribute.  More precisely, it
>        specifies the Router Id of the particular VRF from which this
>        route was exported.

The last sentence says "Router Id". Is it still the OSPF Router ID?
If so, isn't that possible that more than one OSPF process is associated
with a given VRF? If so how a VRF can have "the Router ID"?

>  This attribute is encoded with a two-byte
>        type field, and its type is 0107, with the router id itself
>        carried in the first 4 bytes of the value field.  The type 8001
>        SHOULD be accepted as well, to ensure backwards compatibility,
>        and should be treated as if it were 0107.


>    Routes which a PE receives in type 4 LSAs MUST be ignored.

Sorry, but they can't ignore them. Otherwise, they won't be able to
calculate AS-external routes.

> 4.2.3.1. Intra-Area Routes

>    A sham link can be thought of as a relation between two VRFs.  If two
>    VRFs are to be connected by a sham link, each VRF must be associated
>    with a "Sham Link Endpoint Address", a /32 address which is treated

should be either "a 32-bit IPv4 address" or "a /32 IPv4 prefix"

>    as an address of the PE router containing that VRF.  The Sham Link
>    Endpoint Address associated with a VRF MUST be configurable, and it
>    MAY default to the VRF's router id.

What is the "VRF's router id"?

> The Sham Link Endpoint Address
>    is an address in the VPN's address space, not the SP's address space.

> 4.2.3.2. Creating Sham Links
...
>    IF a VRF is configured for auto-configuration of sham links, it MUST
>    distribute, via BGP, a VPN-IP route corresponding to the Sham Link
>    Endpoint Address.  This route MUST have the OSPF Route Type Extended
>    Community attribute, with the OSPF Route Type field set to "Sham Link
>    Endpoint Address".

What about other fields?

>    When a PE receives such a route, with a Route Target value that
>    allows the route to be imported into a particular VRF, then if

The document should explicitly make it clear that this /32 must be installed
in the VRF routing table, since this is crucial for sham link operation.

Question: if the customer misconfigured one of their routers and a PE receives a
route to the same /32 from another PE as, say, an OSPF internal route, how
should these two types of routes compare?

>      - that route has an OSPF Domain Identifier Extended Communities
>        attribute which is identical to one of the VRF's Domain
>        Identifiers, or the route has no OSPF Domain Identifier Extended
>        Communities attribute and the VRF has a NULL Domain Identifier,
>        AND
>
>      - that route has an OSPF area number which matches that of the VRF,

A VRF may have more than one are per each OSPF process

>    then if the local VRF is configured for auto-configuration of sham
>    links, a sham link is created from the local VRF to the VRF
>    identified by the sham link endpoint address.


> 4.2.3.3. Treatment of Sham Links

This section misses a very important part--sending and receiving OSPF packets
over sham links. Supposedly that would be very similar to OSPF virtual links.

>    The sham link is an unnumbered point-to-point intra-area link, and is
>    advertised by means of a type 1 LSA.

OSPF uses two types of link records in type-1 LSAs: type-1 for physical p2p links,
and type-4 for virtual links. The spec needs to be more specific (heh) which one
is used.

Another really important piece that is missing is next-hop calculation for
routes through Sham Links by the PEs.

And yet another missing piece is what happens with the routes calculated with
next-hops through the sham links. More specifically, should they be preferred
over the BGP ones or not (I assume the PEs continue announcing OSPF routes in
BGP even when a sham link gets established, right?), and how do the packets get
across the MPLS backbone (i.e., how is the MPLS stack gets constructed.)

> 4.2.4. VPN-IP routes received via BGP
>
>    This section describes how the PE router handles VPN-IP routes
>    received via BGP.

Would be useful if this section said explicitly that VPN-IP routes
received via BGP are installed in the VRF's routing table and how
(e.g. as BGP routes).

> 4.2.4.1. Routes from Different Domains

>    To determine how to process an a received VPN-IP route, it is
>    necessary to compare the OSPF Domain Identifier Extended Communities
>    attribute carried by the route (if any) with the OSPF Domain
>    Identifier Extended Communities attribute(s) with which the VRF has
>    been configured (if any).

Previously the text suggested that VRFs are confidered with OSPF Domain IDs,
not extended communities.

> In general, when two such attributes are
>    compared, all eight bytes must be compared.  Thus two OSPF Domain
>    Identifier Extended Communities attributes are regarded as equal if
>    and only if one of the following three conditions holds:
>
>      1. They are identical in all eight bytes.
>
>      2. They are identical in their lower order six bytes (value
>          field), but one attribute has two high order bytes (type field)
>          of 0005 and the other has two high order bytes (type field) of
>          8005.  (This condition is for backwards compatibility.)
>
>      3. The lower order six bytes (value field) of both attributes
>          consist entirely of zeroes.  In this case, the two attributes
>          are considered to be identical irrespective of their type
>          fields, and they are regarded as representing the NULL Domain
>          Identifier.

Given the question above, how applicable is this text?

>    If one of the following three conditions holds, a VPN-IP route
>    received via BGP is regarded as being from a different domain than
>    the VRF into which the route is being installed.
>
>      1. The VRF has a non-NULL OSPF Domain Identifier, but either
>
>            a) the route has no OSPF Domain Identifier Extended
>                Communities attribute, or
>
>            b) the route has an OSPF Domain Identifier Extended
>                Communities attribute whose value field consists of all
>                zeroes
>
>      2. the route has an OSPF Domain Identifier Extended Communities
>          attribute whose value field does not consist of all zeroes, and
>          the VRF is configured with the NULL Domain Identifier (or with
>          any encoding of the NULL Domain Identifier as specified above)

Why would a VRF be configured with "encoding" of a domain id, rather than
simply its value?

>    If any of these three conditions holds, the route is distributed to
>    the CE in a type 5 LSA.

However, in reality, the route will be distributed to an OSPF process, that
may cover one or more CEs. This brings a question: if a VRF is configured with
more than one OSPF PE-CE process, should the received BGP route be distributed
to all OSPF processes by default?

Another important detail here is that the PE must _originate_ that type-5 LSA,
i.e. create an LSA with itself listed as the originating router.

> The VPN Route Tag (see section 4.2.1) MUST
>    be placed in the LSA.  By default, a type 2 metric value is included
>    in the LSA, and by default, its value is taken from the MED attribute
>    of the VPN-IP route.  If the MED is not present, a default metric
>    value is used.

What about the DN bit?
What about the forwarding address?

> 4.2.4.2. Other External Routes
>
>    If the route has an OSPF route type of external route, it MUST be
>    advertised to the CE in a type 5 LSA.

Same comment about announcing to a CE, and LSA origination.
Same question about distribution to multiple OSPF processes.

> The VPN Route Tag (see section
>    4.2.1) MUST be placed in the LSA.

So, is there no way to preserve the original route tag that the customer
may have set at the actual ASBR for redistribution control purposes?

> By default, the MED, if present,
>    is converted to a type 1 or type 2 metric, as determined by the
>    external route property of the VPN-IPv4 route.

Did you mean the "Options" field in the OSPF Route Type attribute here?

>  If no MED is present,
>    a default type 2 metric value is used.

What about the DN bit?
What about the forwarding address?

>    Note that this way of handling AS-external routes makes every PE
>    appear to be an ASBR attached to all the AS-external routes. In a
>    multihomed site, this can result in a number of type 5 LSAs
>    containing the same information.

> 4.2.4.3. Summary Routes
>
>    If the conditions of the previous two sections do not hold, then the
>    route should be treated as if it had been received in an OSPF type 3
>    LSA.

Hmmm.. How about NSSA and Sham link routes?

Another issue:

Because of the backdoor connections between sites, multiple PEs may end up
announcing the same prefix as OSPF routes of different types (e.g. one as
intra-area, one as inter-area). The receiving PE will have to be able to choose
the right route, before or when installing it in the VRF routing table. Hence,
the route selection process that follow the OSPF preference rules will have to
be integrated either in the BGP decision process or in the routing table route
preference algorithm.

[Ballot comment]
!! 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.

[Ballot comment]
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

[Ballot discuss]
> 4.1. Overview

>    Every PE attached to a particular OSPF network MUST function as an
>    OSPF area 0 router.

What does this mean, really? Does it mean that all interfaces should
be treated as belonging to area 0? Hopefully not. That it is a backbone-
connected ABR? If so, in what cases, in particular?
This statement is rather confusing.

>  This allows it to distribute inter-area routes to
>    the CE via Type 3 LSAs.  The CE router might or might not be an area
>    0 router, and the PE/CE link might or might not be an area 0 link.
 
> 4.2. Details
>
> 4.2.1. General
>
>    If a PE and a CE are communicating via OSPF, the PE MUST create, and
>    MUST flood to the CE, a type 1 LSA advertising its link to the CE.
>    The PE MUST have an OSPF router id which is valid (i.e., unique)
>    within the OSPF domain. The PE MUST also be configured to know which
>    OSPF area the link is in.

What is the point of specifying this? "Communicate via OSPF" implies it all.

>    Whether or not the PE-CE link is an area 0 link, the PE MUST function
>    as an OSPF area 0 router.

Same question as above.

>  That is, the link state topology from a
>    site will NOT be passed along by the PE.

Not sassed along where? What if the PE has a Sham Link with another PE?

>    Each OSPF domain MUST be associated with a Domain Identifier.  This
>    MUST be configurable, and the default value (if none is configured)
>    SHOULD be NULL.  More precisely, each VRF associated with an OSPF
>    instance will either be configured with one or more Domain
>    Identifiers, or else will use NULL as its Domain Identifier.

if > 1, does it mean there's more than one OSPF instance associated?

>    If a particular OSPF domain has the NULL Domain Identifier, care must
>    be taken to avoid having routes from that OSPF domain and routes from
>    another OSPF domain imported into the same VRF.

why?

The OSPF Domain ID notion is used, the rules are given, however, the concept is
not explained. I.e, is the goal to be able to tell whether it should look like
one OSPF domain to the customer or multiple? Please provide some description.

>    The value of the VPN Route Tag is arbitrary, but must be distinct
>    from any OSPF Route Tag being used within the OSPF domain.  Its value
>    MUST therefore be configurable.  If the Autonomous System number is
>    two bytes long, the default value SHOULD be an automatically computed
>    tag based on the Autonomous System number of the VPN backbone:

which "the Autonomous System" is meant here?

> 4.2.2. Handling LSAs from the CE
>
>    This section specifies the way in which a PE router handles the OSPF
>    LSAs it receives from a CE router.
>
>    When a PE router receives, from a CE router, any LSA with the DN bit
>    [OSPF-DN] set, the information from that LSA MUST NOT be used by the
>    SPF ("Shortest Path First") computation.  If a Type 5 LSA is received
>    from the CE, and if it has an OSPF route tag value equal to the VPN
>    Route Tag (see section 4.2.1), then the information from that LSA
>    MUST NOT be used by the SPF computation.

Strictly speaking, type-3's and type-5s are not part of "SPF" per se.
a more generic term like "route calculation" would be better.

>    Otherwise, the PE must examine the corresponding VRF. For every

Does this mean the VRF's routing table?

>    address prefix which appears there, the PE must create a VPN-IPv4
>    route in BGP.

Should that rather be "for each route installed by the corresponding OSPF
process"? Otherwise, one could pick up static routes, for example.

>  Each such route will have some of the following
>    Extended Community attributes:

>      - OSPF Route Type Extended Communities Attribute. This attribute
>        MUST be present.  It is encoded with a two-byte type field, and
>        its type is 0306. To ensure backwards compatibility, the type
>        8000 SHOULD be accepted as well, and treated as if it were type
>        0306.  The remaining six bytes of the Attribute are encodes as
>        follows:

and is it left as a reverse-engineering exercise for the reader to figure out
the exact order of these fields?

>          * OSPF Route Type: 1 byte, encoded as follows:
>
>              ** 1 or 2 for intra-area routes (depending on whether the
>                route came from a type 1 or a type 2 LSA -- however this
>                difference is not significant to the procedures
>                specified herein)
>
>              ** 3 for summary routes

this should be "inter-area" routes

>              ** 5 for external routes (area number must be 0)
>
>              ** 7 for NSSA routes.

Processing of NSSA routes hasn't been defined in this spec, btw.

>      - OSPF Router Id Extended Communities Attribute.  This OPTIONAL
>        attribute specifies the OSPF Router Id of the system that is
>        identified in the BGP Next Hop attribute.  More precisely, it
>        specifies the Router Id of the particular VRF from which this
>        route was exported.

The last sentence says "Router Id". Is it still the OSPF Router ID?
If so, isn't that possible that more than one OSPF process is associated
with a given VRF? If so how a VRF can have "the Router ID"?

>  This attribute is encoded with a two-byte
>        type field, and its type is 0107, with the router id itself
>        carried in the first 4 bytes of the value field.  The type 8001
>        SHOULD be accepted as well, to ensure backwards compatibility,
>        and should be treated as if it were 0107.


>    Routes which a PE receives in type 4 LSAs MUST be ignored.

Sorry, but they can't ignore them. Otherwise, they won't be able to
calculate AS-external routes.

> 4.2.3.1. Intra-Area Routes

>    A sham link can be thought of as a relation between two VRFs.  If two
>    VRFs are to be connected by a sham link, each VRF must be associated
>    with a "Sham Link Endpoint Address", a /32 address which is treated

should be either "a 32-bit IPv4 address" or "a /32 IPv4 prefix"

>    as an address of the PE router containing that VRF.  The Sham Link
>    Endpoint Address associated with a VRF MUST be configurable, and it
>    MAY default to the VRF's router id.

What is the "VRF's router id"?

> The Sham Link Endpoint Address
>    is an address in the VPN's address space, not the SP's address space.

> 4.2.3.2. Creating Sham Links
...
>    IF a VRF is configured for auto-configuration of sham links, it MUST
>    distribute, via BGP, a VPN-IP route corresponding to the Sham Link
>    Endpoint Address.  This route MUST have the OSPF Route Type Extended
>    Community attribute, with the OSPF Route Type field set to "Sham Link
>    Endpoint Address".

What about other fields?

>    When a PE receives such a route, with a Route Target value that
>    allows the route to be imported into a particular VRF, then if

The document should explicitly make it clear that this /32 must be installed
in the VRF routing table, since this is crucial for sham link operation.

Question: if the customer misconfigured one of their routers and a PE receives a
route to the same /32 from another PE as, say, an OSPF internal route, how
should these two types of routes compare?

>      - that route has an OSPF Domain Identifier Extended Communities
>        attribute which is identical to one of the VRF's Domain
>        Identifiers, or the route has no OSPF Domain Identifier Extended
>        Communities attribute and the VRF has a NULL Domain Identifier,
>        AND
>
>      - that route has an OSPF area number which matches that of the VRF,

A VRF may have more than one are per each OSPF process

>    then if the local VRF is configured for auto-configuration of sham
>    links, a sham link is created from the local VRF to the VRF
>    identified by the sham link endpoint address.


> 4.2.3.3. Treatment of Sham Links

This section misses a very important part--sending and receiving OSPF packets
over sham links. Supposedly that would be very similar to OSPF virtual links.

>    The sham link is an unnumbered point-to-point intra-area link, and is
>    advertised by means of a type 1 LSA.

OSPF uses two types of link records in type-1 LSAs: type-1 for physical p2p links,
and type-4 for virtual links. The spec needs to be more specific (heh) which one
is used.

Another really important piece that is missing is next-hop calculation for
routes through Sham Links by the PEs.

And yet another missing piece is what happens with the routes calculated with
next-hops through the sham links. More specifically, should they be preferred
over the BGP ones or not (I assume the PEs continue announcing OSPF routes in
BGP even when a sham link gets established, right?), and how do the packets get
across the MPLS backbone (i.e., how is the MPLS stack gets constructed.)

> 4.2.4. VPN-IP routes received via BGP
>
>    This section describes how the PE router handles VPN-IP routes
>    received via BGP.

Would be useful if this section said explicitly that VPN-IP routes
received via BGP are installed in the VRF's routing table and how
(e.g. as BGP routes).

> 4.2.4.1. Routes from Different Domains

>    To determine how to process an a received VPN-IP route, it is
>    necessary to compare the OSPF Domain Identifier Extended Communities
>    attribute carried by the route (if any) with the OSPF Domain
>    Identifier Extended Communities attribute(s) with which the VRF has
>    been configured (if any).

Previously the text suggested that VRFs are confidered with OSPF Domain IDs,
not extended communities.

> In general, when two such attributes are
>    compared, all eight bytes must be compared.  Thus two OSPF Domain
>    Identifier Extended Communities attributes are regarded as equal if
>    and only if one of the following three conditions holds:
>
>      1. They are identical in all eight bytes.
>
>      2. They are identical in their lower order six bytes (value
>          field), but one attribute has two high order bytes (type field)
>          of 0005 and the other has two high order bytes (type field) of
>          8005.  (This condition is for backwards compatibility.)
>
>      3. The lower order six bytes (value field) of both attributes
>          consist entirely of zeroes.  In this case, the two attributes
>          are considered to be identical irrespective of their type
>          fields, and they are regarded as representing the NULL Domain
>          Identifier.

Given the question above, how applicable is this text?

>    If one of the following three conditions holds, a VPN-IP route
>    received via BGP is regarded as being from a different domain than
>    the VRF into which the route is being installed.
>
>      1. The VRF has a non-NULL OSPF Domain Identifier, but either
>
>            a) the route has no OSPF Domain Identifier Extended
>                Communities attribute, or
>
>            b) the route has an OSPF Domain Identifier Extended
>                Communities attribute whose value field consists of all
>                zeroes
>
>      2. the route has an OSPF Domain Identifier Extended Communities
>          attribute whose value field does not consist of all zeroes, and
>          the VRF is configured with the NULL Domain Identifier (or with
>          any encoding of the NULL Domain Identifier as specified above)

Why would a VRF be configured with "encoding" of a domain id, rather than
simply its value?

>    If any of these three conditions holds, the route is distributed to
>    the CE in a type 5 LSA.

However, in reality, the route will be distributed to an OSPF process, that
may cover one or more CEs. This brings a question: if a VRF is configured with
more than one OSPF PE-CE process, should the received BGP route be distributed
to all OSPF processes by default?

Another important detail here is that the PE must _originate_ that type-5 LSA,
i.e. create an LSA with itself listed as the originating router.

> The VPN Route Tag (see section 4.2.1) MUST
>    be placed in the LSA.  By default, a type 2 metric value is included
>    in the LSA, and by default, its value is taken from the MED attribute
>    of the VPN-IP route.  If the MED is not present, a default metric
>    value is used.

What about the DN bit?
What about the forwarding address?

> 4.2.4.2. Other External Routes
>
>    If the route has an OSPF route type of external route, it MUST be
>    advertised to the CE in a type 5 LSA.

Same comment about announcing to a CE, and LSA origination.
Same question about distribution to multiple OSPF processes.

> The VPN Route Tag (see section
>    4.2.1) MUST be placed in the LSA.

So, is there no way to preserve the original route tag that the customer
may have set at the actual ASBR for redistribution control purposes?

> By default, the MED, if present,
>    is converted to a type 1 or type 2 metric, as determined by the
>    external route property of the VPN-IPv4 route.

Did you mean the "Options" field in the OSPF Route Type attribute here?

>  If no MED is present,
>    a default type 2 metric value is used.

What about the DN bit?
What about the forwarding address?

>    Note that this way of handling AS-external routes makes every PE
>    appear to be an ASBR attached to all the AS-external routes. In a
>    multihomed site, this can result in a number of type 5 LSAs
>    containing the same information.

> 4.2.4.3. Summary Routes
>
>    If the conditions of the previous two sections do not hold, then the
>    route should be treated as if it had been received in an OSPF type 3
>    LSA.

Hmmm.. How about NSSA and Sham link routes?

[Ballot discuss]
> 4.1. Overview

>    Every PE attached to a particular OSPF network MUST function as an
>    OSPF area 0 router.

What does this mean, really? Does it mean that all interfaces should
be treated as belonging to area 0? Hopefully not. That it is a backbone-
connected ABR? If so, in what cases, in particular?
This statement is rather confusing.

>  This allows it to distribute inter-area routes to
>    the CE via Type 3 LSAs.  The CE router might or might not be an area
>    0 router, and the PE/CE link might or might not be an area 0 link.
 
> 4.2. Details
>
> 4.2.1. General
>
>    If a PE and a CE are communicating via OSPF, the PE MUST create, and
>    MUST flood to the CE, a type 1 LSA advertising its link to the CE.
>    The PE MUST have an OSPF router id which is valid (i.e., unique)
>    within the OSPF domain. The PE MUST also be configured to know which
>    OSPF area the link is in.

What is the point of specifying this? "Communicate via OSPF" implies it all.

>    Whether or not the PE-CE link is an area 0 link, the PE MUST function
>    as an OSPF area 0 router.

Same question as above.

>  That is, the link state topology from a
>    site will NOT be passed along by the PE.

Not sassed along where? What if the PE has a Sham Link with another PE?

>    Each OSPF domain MUST be associated with a Domain Identifier.  This
>    MUST be configurable, and the default value (if none is configured)
>    SHOULD be NULL.  More precisely, each VRF associated with an OSPF
>    instance will either be configured with one or more Domain
>    Identifiers, or else will use NULL as its Domain Identifier.

if > 1, does it mean there's more than one OSPF instance associated?

>    If a particular OSPF domain has the NULL Domain Identifier, care must
>    be taken to avoid having routes from that OSPF domain and routes from
>    another OSPF domain imported into the same VRF.

why?

The OSPF Domain ID notion is used, the rules are given, however, the concept is
not explained. I.e, is the goal to be able to tell whether it should look like
one OSPF domain to the customer or multiple? Please provide some description.

>    The value of the VPN Route Tag is arbitrary, but must be distinct
>    from any OSPF Route Tag being used within the OSPF domain.  Its value
>    MUST therefore be configurable.  If the Autonomous System number is
>    two bytes long, the default value SHOULD be an automatically computed
>    tag based on the Autonomous System number of the VPN backbone:

which "the Autonomous System" is meant here?

> 4.2.2. Handling LSAs from the CE
>
>    This section specifies the way in which a PE router handles the OSPF
>    LSAs it receives from a CE router.
>
>    When a PE router receives, from a CE router, any LSA with the DN bit
>    [OSPF-DN] set, the information from that LSA MUST NOT be used by the
>    SPF ("Shortest Path First") computation.  If a Type 5 LSA is received
>    from the CE, and if it has an OSPF route tag value equal to the VPN
>    Route Tag (see section 4.2.1), then the information from that LSA
>    MUST NOT be used by the SPF computation.

Strictly speaking, type-3's and type-5s are not part of "SPF" per se.
a more generic term like "route calculation" would be better.

>    Otherwise, the PE must examine the corresponding VRF. For every

Does this mean the VRF's routing table?

>    address prefix which appears there, the PE must create a VPN-IPv4
>    route in BGP.

Should that rather be "for each route installed by the corresponding OSPF
process"? Otherwise, one could pick up static routes, for example.

>  Each such route will have some of the following
>    Extended Community attributes:

>      - OSPF Route Type Extended Communities Attribute. This attribute
>        MUST be present.  It is encoded with a two-byte type field, and
>        its type is 0306. To ensure backwards compatibility, the type
>        8000 SHOULD be accepted as well, and treated as if it were type
>        0306.  The remaining six bytes of the Attribute are encodes as
>        follows:

and is it left as a reverse-engineering exercise for the reader to figure out
the exact order of these fields?

>          * OSPF Route Type: 1 byte, encoded as follows:
>
>              ** 1 or 2 for intra-area routes (depending on whether the
>                route came from a type 1 or a type 2 LSA -- however this
>                difference is not significant to the procedures
>                specified herein)
>
>              ** 3 for summary routes

this should be "inter-area" routes

>              ** 5 for external routes (area number must be 0)
>
>              ** 7 for NSSA routes.

Processing of NSSA routes hasn't been defined in this spec, btw.

>      - OSPF Router Id Extended Communities Attribute.  This OPTIONAL
>        attribute specifies the OSPF Router Id of the system that is
>        identified in the BGP Next Hop attribute.  More precisely, it
>        specifies the Router Id of the particular VRF from which this
>        route was exported.

The last sentence says "Router Id". Is it still the OSPF Router ID?
If so, isn't that possible that more than one OSPF process is associated
with a given VRF? If so how a VRF can have "the Router ID"?

>  This attribute is encoded with a two-byte
>        type field, and its type is 0107, with the router id itself
>        carried in the first 4 bytes of the value field.  The type 8001
>        SHOULD be accepted as well, to ensure backwards compatibility,
>        and should be treated as if it were 0107.


>    Routes which a PE receives in type 4 LSAs MUST be ignored.

Sorry, but they can't ignore them. Otherwise, they won't be able to
calculate AS-external routes.

> 4.2.3.1. Intra-Area Routes

>    A sham link can be thought of as a relation between two VRFs.  If two
>    VRFs are to be connected by a sham link, each VRF must be associated
>    with a "Sham Link Endpoint Address", a /32 address which is treated

should be either "a 32-bit IPv4 address" or "a /32 IPv4 prefix"

>    as an address of the PE router containing that VRF.  The Sham Link
>    Endpoint Address associated with a VRF MUST be configurable, and it
>    MAY default to the VRF's router id.

What is the "VRF's router id"?

> The Sham Link Endpoint Address
>    is an address in the VPN's address space, not the SP's address space.

> 4.2.3.2. Creating Sham Links
...
>    IF a VRF is configured for auto-configuration of sham links, it MUST
>    distribute, via BGP, a VPN-IP route corresponding to the Sham Link
>    Endpoint Address.  This route MUST have the OSPF Route Type Extended
>    Community attribute, with the OSPF Route Type field set to "Sham Link
>    Endpoint Address".

What about other fields?

>    When a PE receives such a route, with a Route Target value that
>    allows the route to be imported into a particular VRF, then if

The document should explicitly make it clear that this /32 must be installed
in the VRF routing table, since this is crucial for sham link operation.

Question: if the customer misconfigured one of their routers and a PE receives a
route to the same /32 from another PE as, say, an OSPF internal route, how
should these two types of routes compare?

>      - that route has an OSPF Domain Identifier Extended Communities
>        attribute which is identical to one of the VRF's Domain
>        Identifiers, or the route has no OSPF Domain Identifier Extended
>        Communities attribute and the VRF has a NULL Domain Identifier,
>        AND
>
>      - that route has an OSPF area number which matches that of the VRF,

The VRF->area mapping again.

>    then if the local VRF is configured for auto-configuration of sham
>    links, a sham link is created from the local VRF to the VRF
>    identified by the sham link endpoint address.


> 4.2.3.3. Treatment of Sham Links

This section misses a very important part--sending and receiving OSPF packets
over sham links. Supposedly that would be very similar to OSPF virtual links.

>    The sham link is an unnumbered point-to-point intra-area link, and is
>    advertised by means of a type 1 LSA.

OSPF uses two type of link records in type-1 LSAs: type-1 for physical p2p links,
and type-4 for virtual links. The spec needs to be more specific (heh) which one
is used.

Another really important piece that is missing is next-hop calculation for
routes through Sham Links by the PEs.

And yet another missing piece is what happens with the routes calculated with
next-hops through the sham links. More specifically, should they be preferred
over the BGP ones or not (I assume the PEs continue announcing OSPF routes in
BGP even when a sham link gets established, right?), and how do the packets get
across the MPLS backbone (i.e., how is the MPLS stack gets constructed.)

> 4.2.4. VPN-IP routes received via BGP
>
>    This section describes how the PE router handles VPN-IP routes
>    received via BGP.

Would be useful if this section said explicitly that VPN-IP routes
received via BGP are installed in the VRF's routing table and how
(e.g. as BGP routes).

> 4.2.4.1. Routes from Different Domains

>    To determine how to process an a received VPN-IP route, it is
>    necessary to compare the OSPF Domain Identifier Extended Communities
>    attribute carried by the route (if any) with the OSPF Domain
>    Identifier Extended Communities attribute(s) with which the VRF has
>    been configured (if any).

Previously the text suggested that VRFs are considered with OSPF Domain IDs,
not extended communities.

> In general, when two such attributes are
>    compared, all eight bytes must be compared.  Thus two OSPF Domain
>    Identifier Extended Communities attributes are regarded as equal if
>    and only if one of the following three conditions holds:
>
>      1. They are identical in all eight bytes.
>
>      2. They are identical in their lower order six bytes (value
>          field), but one attribute has two high order bytes (type field)
>          of 0005 and the other has two high order bytes (type field) of
>          8005.  (This condition is for backwards compatibility.)
>
>      3. The lower order six bytes (value field) of both attributes
>          consist entirely of zeroes.  In this case, the two attributes
>          are considered to be identical irrespective of their type
>          fields, and they are regarded as representing the NULL Domain
>          Identifier.

Given the question above, how applicable is this text?

>    If one of the following three conditions holds, a VPN-IP route
>    received via BGP is regarded as being from a different domain than
>    the VRF into which the route is being installed.
>
>      1. The VRF has a non-NULL OSPF Domain Identifier, but either
>
>            a) the route has no OSPF Domain Identifier Extended
>                Communities attribute, or
>
>            b) the route has an OSPF Domain Identifier Extended
>                Communities attribute whose value field consists of all
>                zeroes
>
>      2. the route has an OSPF Domain Identifier Extended Communities
>          attribute whose value field does not consist of all zeroes, and
>          the VRF is configured with the NULL Domain Identifier (or with
>          any encoding of the NULL Domain Identifier as specified above)

Why would a VRF be configured with "encoding" of a domain id, rather than
simply its value?

>    If any of these three conditions holds, the route is distributed to
>    the CE in a type 5 LSA.

However, in reality, the route will be distributed to an OSPF process, that
may cover one or more CEs. This brings a question: if a VRF is configured with
more than one OSPF PE-CE process, should the received BGP route be distributed
to all OSPF processes by default?

Another important detail here is that the PE must _originate_ that type-5 LSA,
i.e. create an LSA with itself listed as the originating router.

> The VPN Route Tag (see section 4.2.1) MUST
>    be placed in the LSA.  By default, a type 2 metric value is included
>    in the LSA, and by default, its value is taken from the MED attribute
>    of the VPN-IP route.  If the MED is not present, a default metric
>    value is used.

What about the DN bit?
What about the forwarding address?

> 4.2.4.2. Other External Routes
>
>    If the route has an OSPF route type of external route, it MUST be
>    advertised to the CE in a type 5 LSA.

Same comment about announcing to a CE, and LSA origination.
Same question about distribution to multiple OSPF processes.

> The VPN Route Tag (see section
>    4.2.1) MUST be placed in the LSA.

So, is there no way to preserve the original route tag that the customer
may have set at the actual ASBR for redistribution control purposes?

> By default, the MED, if present,
>    is converted to a type 1 or type 2 metric, as determined by the
>    external route property of the VPN-IPv4 route.

Did you mean the "Options" field in the OSPF Route Type attribute here?

>  If no MED is present,
>    a default type 2 metric value is used.

What about the DN bit?
What about the forwarding address?

>    Note that this way of handling AS-external routes makes every PE
>    appear to be an ASBR attached to all the AS-external routes. In a
>    multihomed site, this can result in a number of type 5 LSAs
>    containing the same information.

> 4.2.4.3. Summary Routes
>
>    If the conditions of the previous two sections do not hold, then the
>    route should be treated as if it had been received in an OSPF type 3
>    LSA.

Hmmm.. How about NSSA and Sham link routes?

[Ballot comment]
!! 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?

[Ballot discuss]
Please revise the header and the abstract to indicate that this document is
  an update to RFC 2547 (or rfc2547bis if that is more accurate).

  Please add informative references to BGP and RIP.

  In section 4.2.3.2, the text says:
  >
  > When a PE receives such a route, with a Route Target value that
  > allows the route to be imported into a particular VRF, then if
  >
  >  - that route has an OSPF Domain Identifier Extended Communities
  >    attribute which is identical to one of the VRF's Domain
  >    Identifiers, or the route has no OSPF Domain Identifier Extended
  >    Communities attribute and the VRF has a NULL Domain Identifier,
  >    AND
  >
  >  - that route has an OSPF area number which matches that of the VRF,
  >
  > then if the local VRF is configured for auto-configuration of sham
  > links, a sham link is created from the local VRF to the VRF
  > identified by the sham link endpoint address.
  >
  I find this nesting of conditions very confusing, and I fear that this
  will lead to implementation errors.  I believe that the following rewording
  is more clear, but I am not sure that it captures the original intent.
  Further, I belive that there is a MUST statement that is not captured.
 
    When a PE receives such a route, with a Route Target value that allows
    the route to be imported into a particular VRF, three conditions MUST
    be considered:
 
      1.  Does the route have an OSPF Domain Identifier Extended Communities
          attribute which is identical to one of the VRF's Domain
          Identifiers?  Or, does the route have no OSPF Domain Identifier
          Extended Communities attribute and the VRF have a NULL Domain
          Identifier?

      2.  Does the route have an OSPF area number which matches that of the
          VRF?

      3.  Does the local VRF allow auto-configuration of sham links?

    If all three conditions are met, then a sham link is created from the
    local VRF to the VRF identified by the sham link endpoint address.

[Ballot comment]
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/

State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, erosen@cisco.com, ppsenak@cisco.com, padma@juniper.net from rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com, erosen@cisco.com, ppsenak@cisco.com, padma@juniper.net

[Note]: '2004-11-24: Ready for full IESG review. Also, depends on
draft-ietf-idr-bgp-ext-communities-07.txt to set up IANA registry that
is populated by this document (see comment from IANA in log).
' added by Thomas Narten

IANA Last Call Comments (a day late)
This document puts assignments in a registry that
is set-up by another document (draft-ietf-idr-bgp-ext-communities),
which is currently being clarified.  After the document
creating the registry is clear, IANA will review this
document again to make sure the IANA Considerations section
is appropriate.

From: Thomas Narten
To: "Rick Wilder" , Ross Callon ,
    Ron Bonica
cc: Alex Zinin , erosen@cisco.com, ppsenak@cisco.com,
    padma@juniper.net
Date: Wed, 25 Aug 2004 13:29:17 -0400
Subject: IETF LC on draft-ietf-l3vpn-ospf-2547-01.txt

I reviewed this one a while back, but didn't get around to forwarding
my comments back to the authors. Now that 2547bis has been reviewed by
the IESG, and it appears that the document will be  finished
relatively soon, I'm getting back to the documents that are queued
behind it.

Details of my review below. Nothing major, but I think  a respin is
probably appropriate to at least fix the IANA considerations and lack
of security considerations.

I understand from Alex that the IDR WG has reviewed the document
already.

Make sense?

Thomas


Title contains acronyms.

Abstract is a bit skimpy.


>    is governed via Route Targets.  To meet the above requirements, a PE
>    which imports a particular route into a particular VRF needs to know
>    whether that route comes from the same OSPF domain and the same OSPF

s/which/that/?

>    If two PEs attach to different VPN sites that are in the same OSPF
>    area (as indicated by the OSPF area number), the PE/CE links to those
>    site MAY be treated as links within that area. In addition, each PE
>    MAY flood, into that area, a type 1 LSA advertising a link to the
>    other PE.  If this procedure is followed, two VPN sites in the same
>    OSPF area will see the VPN backbone as a link within that area, a
>    link between the two PE routers.  We refer to this link as a "sham
>    link".  This allows routes from one site to the other to be treated
>    as intra-area routes.  The procedures governing the use of sham links
>    are specified in Section 4.2.3.

Are the above MAYs an operational MAY or an implementation MAY?

>    If the OSPF domain has any area 0 routers (other than the PE
>    routers), then at least one of those MUST be a CE router, and MUST
>    have an area 0 link to at least one PE router. This adjacency MAY be
>    via an OSPF virtual link. This is necessary to ensure that inter-area
>    routes and AS-external routes can be leaked between the PE routers
>    and the non-PE OSPF backbone.

same question.

>    specified in sections 4.2.1 and 4.2.2.  Support for the VPN Route Tag
>    procedures MAY be disabled, when it is no longer necessary.

What does this mean? No longer needs to be implemented as part of the
product? Or does this spec mandate that an operator be able to disable
this capability if desired?

>    Each OSPF domain MUST be associated with a Domain Identifier.  This

reference?

>    the DN bit in type 5 LSAs.  The inclusion of the VPN Route Tag MAY be
>    disabled, if it has been determined that it is no longer needed for
>    backwards compatibility.

Again, I wonder if the intent MUST be implemented, but SP can chose to
disable.

>    If a PE router needs to use OSPF to distribute to a CE router a route
>    which comes from a site outside the CE router's OSPF domain, the PE

s/which/that/ ?

>      - OSPF Route Type Extended Communities Attribute. This attribute
>        MUST be present.  It is encoded with a two-byte type field, and
>        its type is 0306. The type 8000 SHOULD be accepted as well, to
>        ensure backwards compatibility.  The remaining six bytes of the
>        Attribute are encodes as follows:

should 8000 be treated as 0306 on receipt?

Appropriate IANA for new attributs?

Does any of this stuff support IPv6? I think not.. Is that an issue?

>      - MED. By default, this SHOULD be set to the value of the OSPF
>        distance associated with the route, plus 1.

Expand MED on first use?

Needs security considerations section

>    [OSPF-DN] "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP
>    VPNs", draft-ietf-ospf-2547-dnbit-03.txt, Rosen, Psenak, Pillay-

what is  state of this normative reference?

Is there an IANA considerations for this document? should there be?
where are the numbers described here actually allocated?