Subject: NOT GOOD: Fwd: DISCUSS: draft-ietf-l3vpn-ospf-2547

From: Alex Zinin <[email-masked]>
Date: Thu, 2 Dec 2004 11:07:20 -0800

Guys-

 Supposedly this document has been LC'ed in the OSPF WG, and reviewed in
 RTG-DIR, yet I find an _awful_ lot of issues when it comes to the IESG :(
 These should definitely have been caught by these reviews, that's why we
 refer these docs to the experts...

 I'll stop grumbling now and ask this question--how do we make sure
 something like this does not happen again?
 
-- 
Alex
http://www.psg.com/~zinin

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: [email-masked]
Cc: 
Date: Wednesday, December 1, 2004, 11:55:31 PM
Subject: DISCUSS: draft-ietf-l3vpn-ospf-2547

===8<==============Original message text===============

I have so many comments here, I'm not even sure I'm finished reviewing
this doc.

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?

--
Alex

===8<===========End of original message text===========

---

From: Acee Lindem <[email-masked]>
Date: Thu, 02 Dec 2004 14:35:52 -0500

> something like this does not happen again?
Alex,

Not to deflect the issue but I noticed you explicitly sent this E-mail 
to Rohit and I. Note
that this document is a product of the l3vpn WG - not the OSPF wg. Ok - 
now back to
solutions.

Thanks,
Acee

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 08 Dec 2004 18:06:23 +0100

alex:

my 2 cents here...

>  something like this does not happen again?

the question is how to avoid false positive, so the following ideas 
might be considered in addition to the one already in place as i don't 
think they would create any additional overhead (assuming as part of 
point 2 that two sub-sequent reviews would be easier than a single one)

1. keep track on documents that impact routing area protocols that are 
on WG last call, the webpage maintained by bill is a good way to achieve 
  it - this could be a trigger for people listed in 
<http://psg.com/~zinin/ietf/rtg-dir/rtg-dir-skills.html> even if a 
formal review as not been assigned

2. when i-d becomes a wg doc. in a wg outside the routing area provide 
some follow-up (this can be achieved when the document becomes a wg i-d) 
i don't think this can necessarily happen spontaneously, so... a more 
deliberate approach would be advisable here if idea is to keep as 
objective to achieve efficient/fast progress. It could be possible to 
ask for reviews of document external to the routing area when they 
involve routing area protocols (when their status change from individual 
to wg i-d). At the end this could also be complementary to the revision 
of the document when close to be finalized and then have to raise flags 
when implementations are already more progressed

thanks,
- dimitri.