doc: use :term:, will add glossary later

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>

diff --git a/doc/user/eigrpd.rst b/doc/user/eigrpd.rst
index 0af627e1d7329b9780ebb6efb15041959516f27d..a3ad382a9820006d357b67175249fd4bd4f9379a 100644 (file)
--- a/doc/user/eigrpd.rst
+++ b/doc/user/eigrpd.rst
@@ -6,7 +6,7 @@ EIGRP
 
 EIGRP -- Routing Information Protocol is widely deployed interior gateway
 routing protocol. EIGRP was developed in the 1990's. EIGRP is a
-@dfn{distance-vector} protocol and is based on the @dfn{dual} algorithms.
+:term:`distance-vector` protocol and is based on the :term:`dual` algorithms.
 As a distance-vector protocol, the EIGRP router send updates to its
 neighbors as networks change, thus allowing the convergence to a
 known topology.
@@ -33,7 +33,7 @@ EIGRP is like below:
 
   # zebra -d
   # eigrpd -d
-  
+
 
 Please note that *zebra* must be invoked before *eigrpd*.
 
@@ -100,7 +100,7 @@ EIGRP Configuration
     router eigrp 1
      network 10.0.0.0/8
     !
-    
+
 
   Passive interface
 
@@ -114,7 +114,7 @@ EIGRP Configuration
    interface, all receiving packets are ignored and eigrpd does
    not send either multicast or unicast EIGRP packets except to EIGRP neighbors
    specified with `neighbor` command. The interface may be specified
-   as `default` to make eigrpd default to passive on all interfaces. 
+   as `default` to make eigrpd default to passive on all interfaces.
 
    The default is to be passive on all interfaces.
 
@@ -218,9 +218,9 @@ The command displays all EIGRP routes.
   Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply
          r - reply Status, s - sia Status
 
-  P  10.0.2.0/24, 1 successors, FD is 256256, serno: 0 
+  P  10.0.2.0/24, 1 successors, FD is 256256, serno: 0
          via Connected, enp0s3
-  
+
 
 EIGRP Debug Commands
 ====================

diff --git a/doc/user/ospf_fundamentals.rst b/doc/user/ospf_fundamentals.rst
index dc3321ff5e89d3b9eb5b008da1c94322a4361076..6fa0ee176b3f14ff3e03065d73a5d91a4ebca193 100644 (file)
--- a/doc/user/ospf_fundamentals.rst
+++ b/doc/user/ospf_fundamentals.rst
@@ -8,9 +8,9 @@ OSPF Fundamentals
 .. index:: Distance-vector routing protocol
 
 @acronym{OSPF} is, mostly, a link-state routing protocol. In contrast
-to @dfn{distance-vector} protocols, such as @acronym{RIP} or
-@acronym{BGP}, where routers describe available @dfn{paths} (i.e@. routes) 
-to each other, in @dfn{link-state} protocols routers instead
+to :term:`distance-vector` protocols, such as @acronym{RIP} or
+@acronym{BGP}, where routers describe available :term:`paths` (i.e@. routes) 
+to each other, in :term:`link-state` protocols routers instead
 describe the state of their links to their immediate neighbouring
 routers.
 
@@ -25,7 +25,7 @@ routers.
 Each router describes their link-state information in a message known
 as an @acronym{LSA,Link State Advertisement}, which is then propogated
 through to all other routers in a link-state routing domain, by a
-process called @dfn{flooding}. Each router thus builds up an
+process called :term:`flooding`. Each router thus builds up an
 @acronym{LSDB,Link State Database} of all the link-state messages. From
 this collection of LSAs in the LSDB, each router can then calculate the
 shortest path to any other router, based on some common metric, by
@@ -131,7 +131,7 @@ broadly classed as:
 *LSA Flooding*
   OSPF defines several related mechanisms, used to manage synchronisation of
   @acronym{LSDB}s between neighbours as neighbours form adjacencies and
-  the propogation, or @dfn{flooding} of new or updated @acronym{LSA}s.
+  the propogation, or :term:`flooding` of new or updated @acronym{LSA}s.
 
   :ref:`OSPF_Flooding`.
 
@@ -143,13 +143,13 @@ broadly classed as:
   and independent link-state areas. Each area must be connected to a
   common backbone area by an @acronym{ABR,Area Boundary Router}. These
   @acronym{ABR} routers are responsible for summarising the link-state
-  routing information of an area into @dfn{Summary LSAs}, possibly in a
+  routing information of an area into :term:`Summary LSAs`, possibly in a
   condensed (i.e. aggregated) form, and then originating these summaries
   into all other areas the @acronym{ABR} is connected to.
 
   Note that only summaries and external routes are passed between areas.
   As these describe *paths*, rather than any router link-states,
-  routing between areas hence is by @dfn{distance-vector}, @strong{not}
+  routing between areas hence is by :term:`distance-vector`, @strong{not}
   link-state.
 
   :ref:`OSPF_Areas`.
@@ -208,13 +208,13 @@ All LSAs share a common header with the following information:
   from their @acronym{LSDB}s.
 
   The value nominally is one of seconds. An age of 3600, i.e. 1 hour, is
-  called the @dfn{MaxAge}. MaxAge LSAs are ignored in routing
+  called the :term:`MaxAge`. MaxAge LSAs are ignored in routing
   calculations. LSAs must be periodically refreshed by their Advertising
   Router before reaching MaxAge if they are to remain valid.
 
   Routers may deliberately flood LSAs with the age artificially set to
   3600 to indicate an LSA is no longer valid. This is called
-  @dfn{flushing} of an LSA@.
+  :term:`flushing` of an LSA@.
 
   It is not abnormal to see stale LSAs in the LSDB, this can occur where
   a router has shutdown without flushing its LSA(s), e.g. where it has
@@ -236,7 +236,7 @@ protocol.
 
 Instances of these LSAs are specific to the link-state area in which
 they are originated. Routes calculated from these two LSA types are
-called @dfn{intra-area routes}.
+called :term:`intra-area routes`.
 
 * Router LSA
 
@@ -296,7 +296,7 @@ called @dfn{intra-area routes}.
   with the remote router is Full.
 
   Stub links may also be used as a way to describe links on which OSPF is
-  *not* spoken, known as @dfn{passive interfaces}, see :ref:`OSPF_passive-interface,,passive-interface`.
+  *not* spoken, known as :term:`passive interfaces`, see :ref:`OSPF_passive-interface,,passive-interface`.
 
 * Network LSA
 

diff --git a/doc/user/ospfd.rst b/doc/user/ospfd.rst
index 384df6f785ca9b304a4b09a6cdd24c463db7d2f3..db02caefed280b4f3aa28d00f8c504342d1f1b9d 100644 (file)
--- a/doc/user/ospfd.rst
+++ b/doc/user/ospfd.rst
@@ -738,7 +738,7 @@ Redistribute routes to OSPF
                   external routes are not permitted.
 
                   Note that for connected routes, one may instead use
-                  @dfn{passive-interface}, see :ref:`OSPF_passive-interface`.
+                  :term:`passive-interface`, see :ref:`OSPF_passive-interface`.
 
 .. index:: {OSPF Command} {default-information originate} {}
 

diff --git a/doc/user/ripd.rst b/doc/user/ripd.rst
index 7aaaf61778eb3ad72a11b02f663e812338b6c443..f81ddad32a6f2a271c1581b637001a110cd5798d 100644 (file)
--- a/doc/user/ripd.rst
+++ b/doc/user/ripd.rst
@@ -6,8 +6,8 @@ RIP
 
 RIP -- Routing Information Protocol is widely deployed interior gateway
 protocol.  RIP was developed in the 1970s at Xerox Labs as part of the
-XNS routing protocol.  RIP is a @dfn{distance-vector} protocol and is
-based on the @dfn{Bellman-Ford} algorithms.  As a distance-vector
+XNS routing protocol.  RIP is a :term:`distance-vector` protocol and is
+based on the :term:`Bellman-Ford` algorithms.  As a distance-vector
 protocol, RIP router send updates to its neighbors periodically, thus
 allowing the convergence to a known topology.  In each update, the
 distance to any given network will be broadcasted to its neighboring