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

From: Dave Cridland <[email-masked]>
Date: Sat, 2 Feb 2013 21:09:21 +0000

Good Evening,

I have been selected as the Applications Area Directorate reviewer for this
draft.  (For background on appsdir, please see

http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document:

  draft-ietf-ospf-rfc3137bis-03

Title:

  OSPF Stub Router Advertisement

Reviewer:

  Dave Cridland <[email-masked]>

Review Date:

  2 Feb 2013

TL;DR:

This draft discusses ways of having a router visible within OSPF without
offering transit. This seems to be desirable when bringing routers on and
offline, and if a router is present but overloaded.

The document offers a well-defined mechanism suitable for OSPFv2 and
OSPFv3, and points out another strategy only suited to OSPFv3.

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.

Dave.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 5 Feb 2013 18:46:41 +0000

On 2/2/13 9:09 PM, "Dave Cridland" <[email-masked]<mailto:[email-masked]>> 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>

---

From: "White, Russell" <[email-masked]>
Date: Wed, 6 Feb 2013 20:13:54 +0000

I like this text --thanks for putting this together, Alvaro.

:-)

Russ

________________________________
From: Alvaro Retana (aretana) [[email-masked]]
Sent: Tuesday, February 05, 2013 1:46 PM
To: Dave Cridland; [email-masked]; [email-masked]; [email-masked]
Subject: Re: AppsDir Review of draft-ietf-ospf-rfc3137bis-03

Dave:

..

Detail:

Thanks!

Alvaro.

..

---

From: Dave Cridland <[email-masked]>
Date: Fri, 8 Feb 2013 20:18:45 +0000

This looks substantially clearer, thanks.