RIFT: Routing in Fat Trees
draft-ietf-rift-rift-14

gt;.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              DOI 10.17487/RFC1982, August 1996,
              <https://www.rfc-editor.org/info/rfc1982>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2365]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
              RFC 2365, DOI 10.17487/RFC2365, July 1998,
              <https://www.rfc-editor.org/info/rfc2365>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
              <https://www.rfc-editor.org/info/rfc5082>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

   [RFC5709]  Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
              Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
              Authentication", RFC 5709, DOI 10.17487/RFC5709, October
              2009, <https://www.rfc-editor.org/info/rfc5709>.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              DOI 10.17487/RFC5881, June 2010,
              <https://www.rfc-editor.org/info/rfc5881>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

Przygienda, et al.        Expires 17 June 2022                [Page 151]
Internet-Draft                    RIFT                     December 2021

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <https://www.rfc-editor.org/info/rfc6830>.

   [RFC7987]  Ginsberg, L., Wells, P., Decraene, B., Przygienda, T., and
              H. Gredler, "IS-IS Minimum Remaining Lifetime", RFC 7987,
              DOI 10.17487/RFC7987, October 2016,
              <https://www.rfc-editor.org/info/rfc7987>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8202]  Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS
              Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June
              2017, <https://www.rfc-editor.org/info/rfc8202>.

   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.

   [thrift]   Apache Software Foundation, "Thrift Language
              Implementation and Documentation",
              <https://github.com/apache/thrift/tree/0.15.0/doc>.

   [VFR]      Erlebach et al., T., "Cuts and Disjoint Paths in the
              Valley-Free Path Model of Internet BGP Routing", Springer
              Berlin Heidelberg Combinatorial and Algorithmic Aspects of
              Networking, 2005.

11.2.  Informative References

   [APPLICABILITY]
              Wei, Y., Zhang, Z., Afanasiev, D., Thubert, P., and J.
              Kowalczyk, "RIFT Applicability", Work in Progress,
              Internet-Draft, draft-ietf-rift-applicability-09, 12
              December 2021, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rift-applicability-09>.

Przygienda, et al.        Expires 17 June 2022                [Page 152]
Internet-Draft                    RIFT                     December 2021

   [CLOS]     Yuan, X., "On Nonblocking Folded-Clos Networks in Computer
              Communication Environments", IEEE International Parallel &
              Distributed Processing Symposium, 2011.

   [DIJKSTRA] Dijkstra, E. W., "A Note on Two Problems in Connexion with
              Graphs", Journal Numer. Math. , 1959.

   [DYNAMO]   De Candia et al., G., "Dynamo: amazon's highly available
              key-value store", ACM SIGOPS symposium on Operating
              systems principles (SOSP '07), 2007.

   [EPPSTEIN] Eppstein, D., "Finding the k-Shortest Paths", 1997.

   [FATTREE]  Leiserson, C. E., "Fat-Trees: Universal Networks for
              Hardware-Efficient Supercomputing", 1985.

   [IEEEstd1588]
              IEEE, "IEEE Standard for a Precision Clock Synchronization
              Protocol for Networked Measurement and Control Systems",
              IEEE Standard 1588,
              <https://ieeexplore.ieee.org/document/4579760/>.

   [IEEEstd8021AS]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks - Timing and Synchronization for Time-Sensitive
              Applications in Bridged Local Area Networks",
              IEEE Standard 802.1AS,
              <https://ieeexplore.ieee.org/document/5741898/>.

   [RFC0826]  Plummer, D., "An Ethernet Address Resolution Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, DOI 10.17487/RFC0826, November 1982,
              <https://www.rfc-editor.org/info/rfc826>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/info/rfc2131>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

Przygienda, et al.        Expires 17 June 2022                [Page 153]
Internet-Draft                    RIFT                     December 2021

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

   [VAHDAT08] Al-Fares, M., Loukissas, A., and A. Vahdat, "A Scalable,
              Commodity Data Center Network Architecture", SIGCOMM ,
              2008.

   [Wikipedia]
              Wikipedia,
              "https://en.wikipedia.org/wiki/Serial_number_arithmetic",
              2016.

Appendix A.  Sequence Number Binary Arithmetic

   The only reasonably reference to a cleaner than [RFC1982] sequence
   number solution is given in [Wikipedia].  It basically converts the
   problem into two complement's arithmetic.  Assuming a straight two
   complement's subtractions on the bit-width of the sequence number the
   according >: and =: relations are defined as:

      U_1, U_2 are 12-bits aligned unsigned version number

      D_f is  ( U_1 - U_2 ) interpreted as two complement signed 12-bits
      D_b is  ( U_2 - U_1 ) interpreted as two complement signed 12-bits

      U_1 >: U_2 IIF D_f > 0 *and* D_b < 0
      U_1 =: U_2 IIF D_f = 0

   The >: relationship is anti-symmetric but not transitive.  Observe
   that this leaves >: of the numbers having maximum two complement
   distance, e.g. ( 0 and 0x800 ) undefined in the 12-bits case since
   D_f and D_b are both -0x7ff.

   A simple example of the relationship in case of 3-bit arithmetic
   follows as table indicating D_f/D_b values and then the relationship
   of U_1 to U_2:

Przygienda, et al.        Expires 17 June 2022                [Page 154]
Internet-Draft                    RIFT                     December 2021

                  U2 / U1   0    1    2    3    4    5    6    7
                  0        +/+  +/-  +/-  +/-  -/-  -/+  -/+  -/+
                  1        -/+  +/+  +/-  +/-  +/-  -/-  -/+  -/+
                  2        -/+  -/+  +/+  +/-  +/-  +/-  -/-  -/+
                  3        -/+  -/+  -/+  +/+  +/-  +/-  +/-  -/-
                  4        -/-  -/+  -/+  -/+  +/+  +/-  +/-  +/-
                  5        +/-  -/-  -/+  -/+  -/+  +/+  +/-  +/-
                  6        +/-  +/-  -/-  -/+  -/+  -/+  +/+  +/-
                  7        +/-  +/-  +/-  -/-  -/+  -/+  -/+  +/+

                  U2 / U1   0    1    2    3    4    5    6    7
                  0         =    >    >    >    ?    <    <    <
                  1         <    =    >    >    >    ?    <    <
                  2         <    <    =    >    >    >    ?    <
                  3         <    <    <    =    >    >    >    ?
                  4         ?    <    <    <    =    >    >    >
                  5         >    ?    <    <    <    =    >    >
                  6         >    >    ?    <    <    <    =    >
                  7         >    >    >    ?    <    <    <    =

Appendix B.  Information Elements Schema

   This section introduces the schema for information elements.  The IDL
   is Thrift [thrift].

   On schema changes that

   1.   change field numbers *or*

   2.   add new *required* fields *or*

   3.   remove any fields *or*

   4.   change lists into sets, unions into structures *or*

   5.   change multiplicity of fields *or*

   6.   changes name of any field or type *or*

   7.   change data types of any field *or*

   8.   adds, changes or removes a default value of any *existing* field
        *or*

   9.   removes or changes any defined constant or constant value *or*

Przygienda, et al.        Expires 17 June 2022                [Page 155]
Internet-Draft                    RIFT                     December 2021

   10.  changes any enumeration type except extending
        `common.TIETypeType` (use of enumeration types is generally
        discouraged) *or*

   11.  add new TIE type to `TIETypeType` with flooding scope different
        from prefix TIE flooding scope

   major version of the schema MUST increase.  All other changes MUST
   increase minor version within the same major.

   Introducing an optional field does not cause a major version increase
   even if the fields inside the structure are optional with defaults.

   All signed integer as forced by Thrift [thrift] support must be cast
   for internal purposes to equivalent unsigned values without
   discarding the signedness bit.  An implementation SHOULD try to avoid
   using the signedness bit when generating values.

   The schema is normative.

B.1.  Backwards-Compatible Extension of Schema

   The set of rules in Appendix B guarantees that every decoder can
   process serialized content generated by a higher minor version of the
   schema and with that the protocol can progress without a 'fork-lift'.
   Contrary to that, content serialized using a major version X is *not*
   expected to be decodable by any implementation using decoder for a
   model with a major version lower than X.

   Additionally, based on the propagated minor version in encoded
   content and added optional node capabilities new TIE types or even
   de-facto mandatory fields can be introduced without progressing the
   major version albeit only nodes supporting such new extensions would
   decode them.  Given the model is encoded at the source and never re-
   encoded flooding through nodes not understanding any new extensions
   will preserve the according fields.  However, it is important to
   understand that a higher minor version of a schema does *not*
   guarantee that capabilities introduced in lower minors of the same
   major are supported.  The `node_capabilities` field is used to
   indicate which capabilities are supported.

   Specifically, the schema SHOULD add elements to `NodeCapabilities`
   field future capabilities to indicate whether it will support
   interpretation of schema extensions on the same major revision if
   they are present.  Such fields MUST be optional and have an implicit
   or explicit false default value.  If a future capability changes
   route selection or generates blackholes if some nodes are not
   supporting it then a major version increment will be however

Przygienda, et al.        Expires 17 June 2022                [Page 156]
Internet-Draft                    RIFT                     December 2021

   unavoidable.  `NodeCapabilities` shown in LIE MUST match the
   capabilities shown in the Node TIEs, otherwise the behavior is
   unspecified.  A node detecting the mismatch SHOULD generate a
   notification.

   Alternately or additionally, new optional fields can be introduced
   into e.g. `NodeTIEElement` if a special field is chosen to indicate
   via its presence that an optional feature is enabled (since
   capability to support a feature does not necessarily mean that the
   feature is actually configured).

   To support new TIE types without increasing the major version
   enumeration `TIEElement` can be extended with new optional elements
   for new `common.TIETypeType` values as long the scope of the new TIE
   matches the prefix TIE scope.  In case it is necessary to understand
   whether all nodes can parse the new TIE type a node capability MUST
   be added in `NodeCapabilities` to prevent a non-homogenous network.

B.2.  common.thrift

/**
    Thrift file with common definitions for RIFT
*/

namespace py common

/** @note MUST be interpreted in implementation as unsigned 64 bits.
 */
typedef i64      SystemIDType
typedef i32      IPv4Address
/** this has to be long enough to accomodate prefix */
typedef binary   IPv6Address
/** @note MUST be interpreted in implementation as unsigned */
typedef i16      UDPPortType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32      TIENrType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32      MTUSizeType
/** @note MUST be interpreted in implementation as unsigned
    rolling over number */
typedef i64      SeqNrType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32      LifeTimeInSecType
/** @note MUST be interpreted in implementation as unsigned */
typedef i8       LevelType
typedef i16      PacketNumberType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32      PodType

Przygienda, et al.        Expires 17 June 2022                [Page 157]
Internet-Draft                    RIFT                     December 2021

/** @note MUST be interpreted in implementation as unsigned.
          This is carried in the
          security envelope and must hence fit into 8 bits. */
typedef i8       VersionType
/** @note MUST be interpreted in implementation as unsigned */
typedef i16      MinorVersionType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32      MetricType
/** @note MUST be interpreted in implementation as unsigned
          and unstructured */
typedef i64      RouteTagType
/** @note MUST be interpreted in implementation as unstructured
          label value */
typedef i32      LabelType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32      BandwithInMegaBitsType
/** @note Key Value key ID type */
typedef i32      KeyIDType
/** node local, unique identification for a link (interface/tunnel
  * etc. Basically anything RIFT runs on). This is kept
  * at 32 bits so it aligns with BFD [RFC5880] discriminator size.
  */
typedef i32    LinkIDType
/** @note MUST be interpreted in implementation as unsigned,
          especially since we have the /128 IPv6 case. */
typedef i8     PrefixLenType
/** timestamp in seconds since the epoch */
typedef i64    TimestampInSecsType
/** security nonce.
    @note MUST be interpreted in implementation as rolling
          over unsigned value */
typedef i16    NonceType
/** LIE FSM holdtime type */
typedef i16    TimeIntervalInSecType
/** Transaction ID type for prefix mobility as specified by RFC6550,
    value MUST be interpreted in implementation as unsigned  */
typedef i8     PrefixTransactionIDType
/** Timestamp per IEEE 802.1AS, all values MUST be interpreted in
    implementation as unsigned.  */
struct IEEE802_1ASTimeStampType {
    1: required     i64     AS_sec;
    2: optional     i32     AS_nsec;
}
/** generic counter type */
typedef i64 CounterType
/** Platform Interface Index type, i.e. index of interface on hardware,
    can be used e.g. with RFC5837 */
typedef i32 PlatformInterfaceIndex

Przygienda, et al.        Expires 17 June 2022                [Page 158]
Internet-Draft                    RIFT                     December 2021

/** Flags indicating node configuration in case of ZTP.
 */
enum HierarchyIndications {
    /** forces level to `leaf_level` and enables according procedures */
    leaf_only                            = 0,
    /** forces level to `leaf_level` and enables according procedures */
    leaf_only_and_leaf_2_leaf_procedures = 1,
    /** forces level to `top_of_fabric` and enables according
        procedures */
    top_of_fabric                        = 2,
}

const PacketNumberType  undefined_packet_number    = 0
/** used when node is configured as top of fabric in ZTP.*/
const LevelType   top_of_fabric_level              = 24
/** default bandwidth on a link */
const BandwithInMegaBitsType  default_bandwidth    = 100
/** fixed leaf level when ZTP is not used */
const LevelType   leaf_level                  = 0
const LevelType   default_level               = leaf_level
const PodType     default_pod                 = 0
const LinkIDType  undefined_linkid            = 0

/** invalid key for key value */
const KeyIDType   invalid_key_value_key    = 0
/** default distance used */
const MetricType  default_distance         = 1
/** any distance larger than this will be considered infinity */
const MetricType  infinite_distance       = 0x7FFFFFFF
/** represents invalid distance */
const MetricType  invalid_distance        = 0
const bool overload_default               = false
const bool flood_reduction_default        = true
/** default LIE FSM LIE TX internval time */
const TimeIntervalInSecType   default_lie_tx_interval  = 1
/** default LIE FSM holddown time */
const TimeIntervalInSecType   default_lie_holdtime  = 3
/** multipler for default_lie_holdtime to hold down multiple neighbors */
const i8                      multiple_neighbors_lie_holdtime_multipler = 4
/** default ZTP FSM holddown time */
const TimeIntervalInSecType   default_ztp_holdtime  = 1
/** by default LIE levels are ZTP offers */
const bool default_not_a_ztp_offer        = false
/** by default everyone is repeating flooding */
const bool default_you_are_flood_repeater = true
/** 0 is illegal for SystemID */
const SystemIDType IllegalSystemID        = 0
/** empty set of nodes */

Przygienda, et al.        Expires 17 June 2022                [Page 159]
Internet-Draft                    RIFT                     December 2021

const set<SystemIDType> empty_set_of_nodeids = {}
/** default lifetime of TIE is one week */
const LifeTimeInSecType default_lifetime      = 604800
/** default lifetime when TIEs are purged is 5 minutes */
const LifeTimeInSecType purge_lifetime        = 300
/** optional round down interval when TIEs are sent with security hashes
    to prevent excessive computation. **/
const LifeTimeInSecType rounddown_lifetime_interval = 60
/** any `TieHeader` that has a smaller lifetime difference
    than this constant is equal (if other fields equal). */
const LifeTimeInSecType lifetime_diff2ignore  = 400

/** default UDP port to run LIEs on */
const UDPPortType     default_lie_udp_port       =  914
/** default UDP port to receive TIEs on, that can be peer specific */
const UDPPortType     default_tie_udp_flood_port =  915

/** default MTU link size to use */
const MTUSizeType     default_mtu_size           = 1400
/** default link being BFD capable */
const bool            bfd_default                = true

/** undefined nonce, equivalent to missing nonce */
const NonceType       undefined_nonce            = 0;
/** outer security key id, MUST be interpreted as in implementation
    as unsigned */
typedef i8            OuterSecurityKeyID
/** security key id, MUST be interpreted as in implementation
    as unsigned */
typedef i32           TIESecurityKeyID
/** undefined key */
const TIESecurityKeyID undefined_securitykey_id   = 0;
/** Maximum delta (negative or positive) that a mirrored nonce can
    deviate from local value to be considered valid. */
const i16                     maximum_valid_nonce_delta   = 5;
const TimeIntervalInSecType   nonce_regeneration_interval = 300;

/** Direction of TIEs. */
enum TieDirectionType {
    Illegal           = 0,
    South             = 1,
    North             = 2,
    DirectionMaxValue = 3,
}

/** Address family type. */
enum AddressFamilyType {
   Illegal                = 0,

Przygienda, et al.        Expires 17 June 2022                [Page 160]
Internet-Draft                    RIFT                     December 2021

   AddressFamilyMinValue  = 1,
   IPv4     = 2,
   IPv6     = 3,
   AddressFamilyMaxValue  = 4,
}

/** IPv4 prefix type. */
struct IPv4PrefixType {
    1: required IPv4Address    address;
    2: required PrefixLenType  prefixlen;
} (python.immutable = "")

/** IPv6 prefix type. */
struct IPv6PrefixType {
    1: required IPv6Address    address;
    2: required PrefixLenType  prefixlen;
} (python.immutable = "")

/** IP address type. */
union IPAddressType {
    /** Content is IPv4 */
    1: optional IPv4Address   ipv4address;
    /** Content is IPv6 */
    2: optional IPv6Address   ipv6address;
} (python.immutable = "")

/** Prefix advertisement.

    @note: for interface
        addresses the protocol can propagate the address part beyond
        the subnet mask and on reachability computation that has to
        be normalized. The non-significant bits can be used
        for operational purposes.
*/
union IPPrefixType {
    1: optional IPv4PrefixType   ipv4prefix;
    2: optional IPv6PrefixType   ipv6prefix;
} (python.immutable = "")

/** Sequence of a prefix in case of move.
 */
struct PrefixSequenceType {
    1: required IEEE802_1ASTimeStampType  timestamp;
    /** Transaction ID set by client in e.g. in 6LoWPAN. */
    2: optional PrefixTransactionIDType   transactionid;
}

/** Type of TIE.

Przygienda, et al.        Expires 17 June 2022                [Page 161]
Internet-Draft                    RIFT                     December 2021

*/
enum TIETypeType {
    Illegal                                     = 0,
    TIETypeMinValue                             = 1,
    /** first legal value */
    NodeTIEType                                 = 2,
    PrefixTIEType                               = 3,
    PositiveDisaggregationPrefixTIEType         = 4,
    NegativeDisaggregationPrefixTIEType         = 5,
    PGPrefixTIEType                             = 6,
    KeyValueTIEType                             = 7,
    ExternalPrefixTIEType                       = 8,
    PositiveExternalDisaggregationPrefixTIEType = 9,
    TIETypeMaxValue                             = 10,
}

/** RIFT route types.
    @note: The only purpose of those values is to introduce an
           ordering whereas an implementation can choose internally
           any other values as long the ordering is preserved
 */
enum RouteType {
    Illegal               =  0,
    RouteTypeMinValue     =  1,
    /** First legal value. */
    /** Discard routes are most preferred */
    Discard               =  2,

    /** Local prefixes are directly attached prefixes on the
     *  system such as e.g. interface routes.
     */
    LocalPrefix           =  3,
    /** Advertised in S-TIEs */
    SouthPGPPrefix        =  4,
    /** Advertised in N-TIEs */
    NorthPGPPrefix        =  5,
    /** Advertised in N-TIEs */
    NorthPrefix           =  6,
    /** Externally imported north */
    NorthExternalPrefix   =  7,
    /** Advertised in S-TIEs, either normal prefix or positive
        disaggregation */
    SouthPrefix           =  8,
    /** Externally imported south */
    SouthExternalPrefix   =  9,
    /** Negative, transitive prefixes are least preferred */
    NegativeSouthPrefix   = 10,
    RouteTypeMaxValue     = 11,

Przygienda, et al.        Expires 17 June 2022                [Page 162]
Internet-Draft                    RIFT                     December 2021

}

B.3.  encoding.thrift

/**
    Thrift file for packet encodings for RIFT

*/

include "common.thrift"

namespace py encoding

/** Represents protocol encoding schema major version */
const common.VersionType protocol_major_version = 5
/** Represents protocol encoding schema minor version */
const common.MinorVersionType protocol_minor_version =  0

/** Common RIFT packet header. */
struct PacketHeader {
    /** Major version of protocol. */
    1: required common.VersionType      major_version =
            protocol_major_version;
    /** Minor version of protocol. */
    2: required common.MinorVersionType minor_version =
            protocol_minor_version;
    /** Node sending the packet, in case of LIE/TIRE/TIDE
        also the originator of it. */
    3: required common.SystemIDType  sender;
    /** Level of the node sending the packet, required on everything
        except LIEs. Lack of presence on LIEs indicates UNDEFINED_LEVEL
        and is used in ZTP procedures.
     */
    4: optional common.LevelType            level;
}

/** Prefix community. */
struct Community {
    /** Higher order bits */
    1: required i32          top;
    /** Lower order bits */
    2: required i32          bottom;
} (python.immutable = "")

/** Neighbor structure.  */
struct Neighbor {
    /** System ID of the originator. */
    1: required common.SystemIDType        originator;

Przygienda, et al.        Expires 17 June 2022                [Page 163]
Internet-Draft                    RIFT                     December 2021

    /** ID of remote side of the link. */
    2: required common.LinkIDType          remote_id;
} (python.immutable = "")

/** Capabilities the node supports. */
struct NodeCapabilities {
    /** Must advertise supported minor version dialect that way. */
    1: required common.MinorVersionType        protocol_minor_version =
            protocol_minor_version;
    /** indicates that node supports flood reduction. */
    2: optional bool                           flood_reduction =
            common.flood_reduction_default;
    /** indicates place in hierarchy, i.e. top-of-fabric or
        leaf only (in ZTP) or support for leaf-2-leaf
        procedures. */
    3: optional common.HierarchyIndications    hierarchy_indications;
} (python.immutable = "")

/** Link capabilities. */
struct LinkCapabilities {
    /** Indicates that the link is supporting BFD. */
    1: optional bool                           bfd =
            common.bfd_default;
    /** Indicates whether the interface will support IPv4 forwarding. */
    2: optional bool                           ipv4_forwarding_capable =
            true;
} (python.immutable = "")

/** RIFT LIE Packet.

    @note: this node's level is already included on the packet header
*/
struct LIEPacket {
    /** Node or adjacency name. */
    1: optional string                    name;
    /** Local link ID. */
    2: required common.LinkIDType         local_id;
    /** UDP port to which we can receive flooded TIEs. */
    3: required common.UDPPortType        flood_port =
            common.default_tie_udp_flood_port;
    /** Layer 3 MTU, used to discover mismatch. */
    4: optional common.MTUSizeType        link_mtu_size =
            common.default_mtu_size;
    /** Local link bandwidth on the interface. */
    5: optional common.BandwithInMegaBitsType
            link_bandwidth = common.default_bandwidth;
    /** Reflects the neighbor once received to provide
        3-way connectivity. */

Przygienda, et al.        Expires 17 June 2022                [Page 164]
Internet-Draft                    RIFT                     December 2021

    6: optional Neighbor                  neighbor;
    /** Node's PoD. */
    7: optional common.PodType            pod =
            common.default_pod;
    /** Node capabilities supported. */
   10: required NodeCapabilities          node_capabilities;
   /** Capabilities of this link. */
   11: optional LinkCapabilities          link_capabilities;
   /** Required holdtime of the adjacency, i.e. for how
       long a period should adjacency be kept up without valid LIE reception. */
   12: required common.TimeIntervalInSecType
            holdtime = common.default_lie_holdtime;
   /** Optional, unsolicited, downstream assigned locally significant label
       value for the adjacency. */
   13: optional common.LabelType          label;
    /** Indicates that the level on the LIE must not be used
        to derive a ZTP level by the receiving node. */
   21: optional bool                      not_a_ztp_offer =
            common.default_not_a_ztp_offer;
   /** Indicates to northbound neighbor that it should
       be reflooding TIEs received from this node to achieve flood
       reduction and balancing for northbound flooding. */
   22: optional bool                      you_are_flood_repeater =
             common.default_you_are_flood_repeater;
   /** Indicates to neighbor to flood node TIEs only and slow down
       all other TIEs. Ignored when received from southbound neighbor. */
   23: optional bool                      you_are_sending_too_quickly =
             false;
   /** Instance name in case multiple RIFT instances running on same
       interface. */
   24: optional string                    instance_name;
}

/** LinkID pair describes one of parallel links between two nodes. */
struct LinkIDPair {
    /** Node-wide unique value for the local link. */
    1: required common.LinkIDType      local_id;
    /** Received remote link ID for this link. */
    2: required common.LinkIDType      remote_id;

    /** Describes the local interface index of the link. */
   10: optional common.PlatformInterfaceIndex platform_interface_index;
   /** Describes the local interface name. */
   11: optional string                        platform_interface_name;
   /** Indicates whether the link is secured, i.e. protected by
       outer key, absence of this element means no indication,
       undefined outer key means not secured. */
   12: optional common.OuterSecurityKeyID

Przygienda, et al.        Expires 17 June 2022                [Page 165]
Internet-Draft                    RIFT                     December 2021

                trusted_outer_security_key;
   /** Indicates whether the link is protected by established
       BFD session. */
   13: optional bool                          bfd_up;
   /** Optional indication which address families are up on the
       interface */
   14: optional set<common.AddressFamilyType>
       (python.immutable = "")                address_families;
} (python.immutable = "")

/** Unique ID of a TIE. */
struct TIEID {
    /** direction of TIE */
    1: required common.TieDirectionType    direction;
    /** indicates originator of the TIE */
    2: required common.SystemIDType        originator;
    /** type of the tie */
    3: required common.TIETypeType         tietype;
    /** number of the tie */
    4: required common.TIENrType           tie_nr;
} (python.immutable = "")

/** Header of a TIE. */
struct TIEHeader {
    /** ID of the tie. */
    2: required TIEID                             tieid;
    /** Sequence number of the tie. */
    3: required common.SeqNrType                  seq_nr;

    /** Absolute timestamp when the TIE was generated. */
   10: optional common.IEEE802_1ASTimeStampType   origination_time;
   /** Original lifetime when the TIE was generated.  */
   12: optional common.LifeTimeInSecType          origination_lifetime;
}

/** Header of a TIE as described in TIRE/TIDE.
*/
struct TIEHeaderWithLifeTime {
    1: required     TIEHeader                       header;
    /** Remaining lifetime. */
    2: required     common.LifeTimeInSecType        remaining_lifetime;
}

/** TIDE with *sorted* TIE headers. */
struct TIDEPacket {
    /** First TIE header in the tide packet. */
    1: required TIEID                       start_range;
    /** Last TIE header in the tide packet. */

Przygienda, et al.        Expires 17 June 2022                [Page 166]
Internet-Draft                    RIFT                     December 2021

    2: required TIEID                       end_range;
    /** _Sorted_ list of headers. */
    3: required list<TIEHeaderWithLifeTime>
       (python.immutable = "")              headers;
}

/** TIRE packet */
struct TIREPacket {
    1: required set<TIEHeaderWithLifeTime>
       (python.immutable = "")              headers;
}

/** neighbor of a node */
struct NodeNeighborsTIEElement {
    /** level of neighbor */
    1: required common.LevelType                level;
    /**  Cost to neighbor. Ignore anything larger than `infinite_distance` and `invalid_distance` */
    3: optional common.MetricType               cost
                = common.default_distance;
    /** can carry description of multiple parallel links in a TIE */
    4: optional set<LinkIDPair>
       (python.immutable = "")                  link_ids;
    /** total bandwith to neighbor as sum of all parallel links */
    5: optional common.BandwithInMegaBitsType
                bandwidth = common.default_bandwidth;
} (python.immutable = "")

/** Indication flags of the node. */
struct NodeFlags {
    /** Indicates that node is in overload, do not transit traffic
        through it. */
    1: optional bool         overload = common.overload_default;
} (python.immutable = "")

/** Description of a node. */
struct NodeTIEElement {
    /** Level of the node. */
    1: required common.LevelType            level;
    /** Node's neighbors. Multiple node TIEs can carry disjoint sets of neighbors. */
    2: required map<common.SystemIDType,
                NodeNeighborsTIEElement>    neighbors;
    /** Capabilities of the node. */
    3: required NodeCapabilities            capabilities;
    /** Flags of the node. */
    4: optional NodeFlags                   flags;
    /** Optional node name for easier operations. */
    5: optional string                      name;
    /** PoD to which the node belongs. */

Przygienda, et al.        Expires 17 June 2022                [Page 167]
Internet-Draft                    RIFT                     December 2021

    6: optional common.PodType              pod;
    /** optional startup time of the node */
    7: optional common.TimestampInSecsType  startup_time;

    /** If any local links are miscabled, this indication is flooded. */
   10: optional set<common.LinkIDType>
        (python.immutable = "")             miscabled_links;

} (python.immutable = "")

/** Attributes of a prefix. */
struct PrefixAttributes {
    /** Distance of the prefix. */
    2: required common.MetricType            metric
            = common.default_distance;
    /** Generic unordered set of route tags, can be redistributed
        to other protocols or use within the context of real time
        analytics. */
    3: optional set<common.RouteTagType>
       (python.immutable = "")               tags;
    /** Monotonic clock for mobile addresses.  */
    4: optional common.PrefixSequenceType    monotonic_clock;
    /** Indicates if the prefix is a node loopback. */
    6: optional bool                         loopback = false;
    /** Indicates that the prefix is directly attached. */
    7: optional bool                         directly_attached = true;
    /** link to which the address belongs to.  */
   10: optional common.LinkIDType            from_link;
} (python.immutable = "")

/** TIE carrying prefixes */
struct PrefixTIEElement {
    /** Prefixes with the associated attributes. */
    1: required map<common.IPPrefixType, PrefixAttributes> prefixes;
} (python.immutable = "")

/** Generic key value pairs. */
struct KeyValueTIEElement {
    1: required map<common.KeyIDType, binary>    keyvalues;
} (python.immutable = "")

/** Single element in a TIE. */
union TIEElement {
    /** Used in case of enum common.TIETypeType.NodeTIEType. */
    1: optional NodeTIEElement     node;
    /** Used in case of enum common.TIETypeType.PrefixTIEType. */
    2: optional PrefixTIEElement          prefixes;
    /** Positive prefixes (always southbound). */

Przygienda, et al.        Expires 17 June 2022                [Page 168]
Internet-Draft                    RIFT                     December 2021

    3: optional PrefixTIEElement   positive_disaggregation_prefixes;
    /** Transitive, negative prefixes (always southbound) */
    5: optional PrefixTIEElement   negative_disaggregation_prefixes;
    /** Externally reimported prefixes. */
    6: optional PrefixTIEElement          external_prefixes;
    /** Positive external disaggregated prefixes (always southbound). */
    7: optional PrefixTIEElement
            positive_external_disaggregation_prefixes;
    /** Key-Value store elements. */
    9: optional KeyValueTIEElement keyvalues;
} (python.immutable = "")

/** TIE packet */
struct TIEPacket {
    1: required TIEHeader  header;
    2: required TIEElement element;
}

/** Content of a RIFT packet. */
union PacketContent {
    1: optional LIEPacket     lie;
    2: optional TIDEPacket    tide;
    3: optional TIREPacket    tire;
    4: optional TIEPacket     tie;
}

/** RIFT packet structure. */
struct ProtocolPacket {
    1: required PacketHeader  header;
    2: required PacketContent content;
}

Appendix C.  Constants

C.1.  Configurable Protocol Constants

   This section gathers constants that are provided in the schema files
   and in the document.

Przygienda, et al.        Expires 17 June 2022                [Page 169]
Internet-Draft                    RIFT                     December 2021

   +================+==============+==================================+
   |                | Type         | Value                            |
   +================+==============+==================================+
   | LIE IPv4       | Default      | 224.0.0.120 or all-rift-routers  |
   | Multicast      | Value,       | to be assigned in IPv4 Multicast |
   | Address        | Configurable | Address Space Registry in Local  |
   |                |              | Network Control Block            |
   +----------------+--------------+----------------------------------+
   | LIE IPv6       | Default      | FF02::A1F7 or all-rift-routers   |
   | Multicast      | Value,       | to be assigned in IPv6 Multicast |
   | Address        | Configurable | Address Assignments              |
   +----------------+--------------+----------------------------------+
   | LIE            | Default      | 914                              |
   | Destination    | Value,       |                                  |
   | Port           | Configurable |                                  |
   +----------------+--------------+----------------------------------+
   | Level value    | Constant     | 24                               |
   | for            |              |                                  |
   | TOP_OF_FABRIC  |              |                                  |
   | flag           |              |                                  |
   +----------------+--------------+----------------------------------+
   | Default LIE    | Default      | 3 seconds                        |
   | Holdtime       | Value,       |                                  |
   |                | Configurable |                                  |
   +----------------+--------------+----------------------------------+
   | TIE            | Default      | 1 second                         |
   | Retransmission | Value        |                                  |
   | Interval       |              |                                  |
   +----------------+--------------+----------------------------------+
   | TIDE           | Default      | 5 seconds                        |
   | Generation     | Value,       |                                  |
   | Interval       | Configurable |                                  |
   +----------------+--------------+----------------------------------+
   | MIN_TIEID      | Constant     | TIE Key with minimal values:     |
   | signifies      |              | TIEID(originator=0,              |
   | start of TIDEs |              | tietype=TIETypeMinValue,         |
   |                |              | tie_nr=0, direction=South)       |
   +----------------+--------------+----------------------------------+
   | MAX_TIEID      | Constant     | TIE Key with maximal values:     |
   | signifies end  |              | TIEID(originator=MAX_UINT64,     |
   | of TIDEs       |              | tietype=TIETypeMaxValue,         |
   |                |              | tie_nr=MAX_UINT64,               |
   |                |              | direction=North)                 |
   +----------------+--------------+----------------------------------+

                         Table 41: all_constants

Przygienda, et al.        Expires 17 June 2022                [Page 170]
Internet-Draft                    RIFT                     December 2021

Authors' Addresses

   Tony Przygienda (editor)
   Juniper
   1137 Innovation Way
   Sunnyvale, CA
   United States of America

   Email: prz@juniper.net

   Alankar Sharma
   Comcast
   1800 Bishops Gate Blvd
   Mount Laurel, NJ 08054
   United States of America

   Email: as3957@gmail.com

   Pascal Thubert
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   06254 MOUGINS - Sophia Antipolis
   France

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com

   Bruno Rijsman
   Individual

   Email: brunorijsman@gmail.com

   Dmitry Afanasiev
   Yandex

   Email: fl0w@yandex-team.ru

Przygienda, et al.        Expires 17 June 2022                [Page 171]