Applicability, Use-cases, and Architecture for the CRH

[Ron Bonica <[e-mail]>]

Darren,
In previous emails, you suggest that the CRH draft needs information regarding Applicability, Use-cases and Architecture. After the call for adoption, we could add the proposed text, below.
Would this text address your concerns. If not, please provide specific recommendations.
                                                                         Ron

PROPOSED TEXT
----------------------

9.0 Applicability

The CRH can be used within any network where:

  *   All nodes implement IPv6.
  *   Edge node can filter inbound packets that contain the CRH.
  *   Selected nodes can process the CRH. If a node is identified in a CRH, and it is not the packet's ultimate destination, it must be able to process the CRH.
  *   All nodes can maintain a basic FIB that maps IPv6 prefixes to next-hops.
  *   Selected nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and forwarding methods. If a node is identified in a CRH, and it is not the packet's ultimate destination, it must be able to
  *   CRH overhead is acceptable
CRH-16  overhead is as follows:

  *   2 SIDs can be stored in a 8-byte CRH
  *   6 SIDs can be stored in a 16-byte CRH
  *   10 SIDs can be stored in a 24-byte CRH
  *   14 SIDs can be stored in a 32-byte CRH
  *   Etc.
CRH-32  overhead is as follows:

  *   1 SIDs can be stored in a 8-byte CRH
  *   3 SIDs can be stored in a 16-byte CRH
  *   5 SIDs can be stored in a 24-byte CRH
  *   7 SIDs can be stored in a 32-byte CRH
  *   Etc.

10.0 Use-cases

The CRH can be used to provide traffic steering in:


  *   Data centers
  *   Service provider networks
  *   Enterprise networks
Each of these networks may have a preferred method for populating the basic FIB and the CRH-FIB. For example, a data center may use a controller to populate both FIBs while a service provider may use an IGP to populate both FIBs.
The CRH can implemented on:

  *   ASIC-based routers
  *   Software-based routers
     *   Stand-alone
     *   In a container on a server in a data center


11.0 Architecture

CRH architecture determined entirely by RFC 8200. Specifically:


  *   IPv6 source nodes use the CRH to determine nodes that a packet visits on route to is ultimate destination.
  *   The CRH does not subsume the function of any other IPv6 extension header. For example, the CRH cannot be used for authentication, or to deliver optional internet-layer information to the packet's ultimate destination node.
  *   A packet that contains the CRH can also contain any valid combination of IPv6 extension headers. All extension header should function as per their specifications.
  *   The CRH assumes that IPv6 Destination Address semantics are as defined in RFC 8200 and RFC 4291.
  *   The CRH is processed identically on every node (See Section 5 of this document). Processing rules do not depend upon information encoded in the IPv6 Destination Address.
  *
The CRH conforms to the letter and spirit of RFC 8200. For example:

  *   A packet cannot contain two instances of the CRH
  *   A CRH cannot be added or deleted by any node along a packet's processing path




Juniper Business Use Only