anchor.diff:    passes through to DUP. DUP does it's normal collection-level processing that may involve routing the document
     to another shard & replica.
   
  -* If the time stamp on the document is more recent than the most recent TRA segment, then a new collection needs to be
  +* If the timestamp on the document is more recent than the most recent TRA segment, then a new collection needs to be
     added at the front of the TRA.
  -  TRUP will create this collection, add it to the alias and then forward the document to the collection it just created.
  +  RAUP will create this collection, add it to the alias, and then forward the document to the collection it just created.
     This can happen recursively if more than one collection needs to be created.
   +
   Each time a new collection is added, the oldest collections in the TRA are examined for possible deletion, if that has
       been configured.
   All this happens synchronously, potentially adding seconds to the update request and indexing latency.
  ++
   If `router.preemptiveCreateMath` is configured and if the document arrives within this window then it will occur
  -asynchronously.
  -
  -Any other type of update like a commit or delete is routed by TRUP to all collections.
  +asynchronously. See <<collections-api.adoc#time-routed-alias-parameters,Time Routed Alias Parameters>> for more information.
  +
  +Any other type of update like a commit or delete is routed by RAUP to all collections.
   Generally speaking, this is not a performance concern. When Solr receives a delete or commit wherein nothing is deleted
   or nothing needs to be committed, then it's pretty cheap.
   
  -
  -=== Limitations & Assumptions
  -
  -* Only *time* routed aliases are supported.  If you instead have some other sequential number, you could fake it
  +==== Limitations & Assumptions
  +
  +* Only *time* routed aliases are supported. If you instead have some other sequential number, you could fake it
     as a time (e.g., convert to a timestamp assuming some epoch and increment).
   +
   The smallest possible interval is one second.
   No other routing scheme is supported, although this feature was developed with considerations that it could be
     extended/improved to other schemes.
   
  -* The underlying collections form a contiguous sequence without gaps.  This will not be suitable when there are
  -  large gaps in the underlying data, as Solr will insist that there be a collection for each increment.  This
  -  is due in part on Solr calculating the end time of each interval collection based on the timestamp of
  +* The underlying collections form a contiguous sequence without gaps. This will not be suitable when there are
  +  large gaps in the underlying data, as Solr will insist that there be a collection for each increment. This
  +  is due in part to Solr calculating the end time of each interval collection based on the timestamp of
     the next collection, since it is otherwise not stored in any way.
   
   * Avoid sending updates to the oldest collection if you have also configured that old collections should be
  -  automatically deleted.  It could lead to exceptions bubbling back to the indexing client.
  -
  -== Category Routed Aliases
  -
  -Starting in Solr 8.1, Category Routed Aliases (CRAs) are a feature to manage aliases and a set of dependent collections
  +  automatically deleted. It could lead to exceptions bubbling back to the indexing client.
  +
  +=== Category Routed Aliases
  +
  +Category Routed Aliases (CRAs) are a feature to manage aliases and a set of dependent collections
   based on the value of a single field.
   
   CRAs automatically create new collections but because the partitioning is on categorical information rather than continuous
   numerically based values there's no logic for automatic deletion. This approach allows for simplified indexing of data
   that must be segregated into collections for cluster management or security reasons.
   
  -=== How It Works
  -
  -First you create a time routed aliases using the <<collections-api.adoc#createalias,CREATEALIAS>> command with some
  -  router settings.
  +==== How It Works
  +
  +First you create a category routed alias using the <<collections-api.adoc#createalias,CREATEALIAS>> command with the
  +desired router settings.
    Most of the settings are editable at a later time using the <<collections-api.adoc#aliasprop,ALIASPROP>> command.
   
   The alias will be created with a special place-holder collection which will always be named
  - `myAlias__CRA__NEW_CATEGORY_ROUTED_ALIAS_WAITING_FOR_DATA__TEMP`. The first document indexed into the CRA
  + `myAlias\__CRA__NEW_CATEGORY_ROUTED_ALIAS_WAITING_FOR_DATA\__TEMP`. The first document indexed into the CRA
    will create a second collection named `myAlias__CRA__foo` (for a routed field value of `foo`). The second document
    indexed will cause the temporary place holder collection to be deleted. Thereafter collections will be created whenever
    a new value for the field is encountered.
   
   CAUTION: To guard against runaway collection creation options for limiting the total number of categories, and for
  -rejecting values that don't match a regular expression are provided (see <<collections-api.adoc#createalias,CREATEALIAS>> for
  -details). Note that by providing very large or very permissive values for these options you are accepting the risk that
  +rejecting values that don't match, a regular expression parameter is provided (see <<collections-api.adoc#category-routed-alias-parameters,Category Routed Alias Parameters>> for
  +details).
  ++
  +Note that by providing very large or very permissive values for these options you are accepting the risk that
   garbled data could potentially create thousands of collections and bring your cluster to a grinding halt.
   
  -Please note that the values (and thus the collection names) are case sensitive. As elsewhere in Solr manipulation and
  -cleaning of the data is expected to be done by external processes before data is sent to Solr with one exception.
  +Field values (and thus the collection names) are case sensitive.
  +
  +As elsewhere in Solr, manipulation and
  +cleaning of the data is expected to be done by external processes before data is sent to Solr, with one exception.
   Throughout Solr there are limitations on the allowable characters in collection names. Any characters other than ASCII
   alphanumeric characters (`A-Za-z0-9`), hyphen (`-`) or underscore (`_`) are replaced with an underscore when calculating
   the collection name for a category. For a CRA named `myAlias` the following table shows how collection names would be
  
positive.code: There is no automated means of removing a category. If a category needs to be removed from a CRA
  the following procedure is recommended:
  
  . Ensure that no documents with the value corresponding to the category to be removed will be sent
     either by stopping indexing or by fixing the incoming data stream
  . Modify the alias definition in zookeeper, removing the collection corresponding to the category.
  . Delete the collection corresponding to the category. Note that if the collection is not removed
     from the alias first, this step will fail.
  
  === Limitations & Assumptions
  
  * CRAs are presently unsuitable for non-english data values due to the limits on collection names.
    This can be worked around by duplicating the route value to a *_url safe_* base 64 encoded field
    and routing on that value instead.
  
  * The check for the __CRA__ infix is independent of the regular expression validation and occurs after
    the name of the collection to be created has been calculated. It may not be avoided and is necessary
    to support future features.
  
  == Improvement Possibilities
  
  Routed aliases are a relatively new feature of SolrCloud that can be expected to be improved.
  Some _potential_ areas for improvement that _are not implemented yet_ are:
  
negative.code: If you need to store a lot of timestamped data in Solr, such as logs or IoT sensor data, then this feature probably
    makes more sense than creating one sharded hash-routed collection.
  
  ==== How It Works
  
  First you create a time routed aliases using the <<collections-api.adoc#createalias,CREATEALIAS>> command with the
  desired router settings.
  Most of the settings are editable at a later time using the <<collections-api.adoc#aliasprop,ALIASPROP>> command.
  
  The first collection will be created automatically, along with an alias pointing to it.
  