Re: [apps-discuss] AppsDir Review of draft-ietf-ospf-rfc3137bis-03

["Alvaro Retana (aretana)" <[e-mail]>]

On 2/2/13 9:09 PM, "Dave Cridland" <[e-mail]<mailto:[e-mail]>> wrote:

Dave:

First of all, thanks for the review!

..
For the most part this draft seems ready for publication, though I'm concerned it offers confusing guidance on which mechanism to use, and some wordsmithing is needed here.

Detail:

§2.1 suggests it is a "similar, if not better" solution available to OSPFv3 networks. It's not clear to me if this means "similar, and potentially better", or "similar, but not better". The second paragraph is also somewhat loose in whether this technique is recommended or not.

It's not clear to me if the portion following the semicolon is essentially saying that the R-bit is superior; this is not helped by being unclear if "more granular" means finer or coarser. A quick trip to Wikipedia didn't help me, either, apparently it depends on whether the R-bit is photographic, sugary, or something else.

My guess, without looking at the OSPFv3 specification, is that this technique is liable to be better by dint of the R-bit applying to individual prefixes - that is, the technique is "similar, and usually better", because the R-bit provides a "more specific", or possibly "individual" indication of whether a router is active. This may be wrong, in which case it's a perfect illustration of why it's confusing.

We tried not to pass judgement as to which mechanism was better, since it depends on what the operator wants to do in the network: allow transit as a last resort or not at all.  We tried to say something about that in the 'Deployment Consideration' section, but I do agree that we could make it clearer.  The use of 'granular' is specially confusing as the R-bit is used to indicate whether the whole router is active (and should be used for transit) or not, versus the MaxLinkMetric option which expects all the non-stub links to use it.

I put some proposed text below.  In it we're clarifying the text in 2.1 and added a paragraph at the end of 4.  Please let me know if this is still not clear.

Thanks!

Alvaro.

2.1.  OSPFv3-only Solution

   OSPFv3 [RFC5340] introduced additional options to provide similar
   control of the forwarding topology; the R-bit provides an indication
   of whether a router is active and should be used for transit traffic.

   It is left to network operators to decide which technique to use in
   their network.  See Section 4 for more details.

..

4.  Deployment Considerations

   When using MaxLinkMetric, some inconsistency may be seen if the
   network is constructed of routers that perform intra-area Dijkstra
   calculation as specified in [RFC1247] (discarding link records in
   router-LSAs that have a MaxLinkMetric cost value) and routers that
   perform it as specified in [RFC1583] and higher (do not treat links
   with MaxLinkMetric cost as unreachable).  Note that this
   inconsistency will not lead to routing loops, because if there are
   some alternate paths in the network, both types of routers will agree
   on using them rather than the path through the stub router.  If the
   path through the stub router is the only one, the routers of the
   first type will not use the stub router for transit (which is the
   desired behavior), while the routers of the second type will still
   use this path.

   On the other hand, clearing the R-bit will consistently result in the
   router not being used as transit.

   The use of MaxLinkMetric or the R-bit in a network depends on the
   objectives of the operator.  One of the possible considerations for
   selecting one or the other is in the desired behavior if the path
   through the stub router is the only one available.  Using MaxLinkMetric
   allows for that path to be used, while the R-bit doesn't.

<http://tools.ietf.org/html/draft-ietf-ospf-rfc3137bis-03#section-3>