rtgwg                                                           Z. Zhang
Internet-Draft                                                   K. Wang
Intended status: Standards Track                        Juniper Networks
Expires: 22 March 2025                                            C. Lin
                                                    New H3C Technologies
                                                               N. Vaidya
                                                                Broadcom
                                                       18 September 2024


                     Advertising Router Information
                   draft-zzhang-rtgwg-router-info-01

Abstract

   This document specifies a generic mechanism for a router to advertise
   some information to its neighbors.  One use case of this mechanism is
   to advertise link/path information so that a receiving router can
   better react to network changes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 March 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Zhang, et al.             Expires 22 March 2025                 [Page 1]

Internet-Draft       Advertising Router Information       September 2024


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Neighbor Path Information . . . . . . . . . . . . . . . .   5
     2.2.  Link Information  . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Refreshing and Aging  . . . . . . . . . . . . . . . . . .   8
     2.4.  Refresh Rate Negotiation  . . . . . . . . . . . . . . . .   8
     2.5.  Flow Redirection  . . . . . . . . . . . . . . . . . . . .   9
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   [I-D.wang-idr-next-next-hop-nodes] describes a scenario where better
   load-balancing can be achieved in a CLOS network by considering the
   load information on the next hop router in addition to considering
   the local load information of the path to that next hop router.

   [I-D.liu-rtgwg-path-aware-remote-protection] describes another
   scenario where link up/down information propagated via non-IGP
   mechanism can help with faster reroute.

   [I-D.cheng-rtgwg-adaptive-routing-framework] describes a framework
   for Adaptive Routing which dynamically adjusts routing paths based on
   changes in global network conditions, thereby optimizing network
   performance and resource utilization.

   To achieve that, a router needs to advertise some link/path
   information independently of IGP.  This document specifies a
   mechanism to do that.  It can also be used to advertise any
   information.





Zhang, et al.             Expires 22 March 2025                 [Page 2]

Internet-Draft       Advertising Router Information       September 2024


   As described in [I-D.wang-idr-next-next-hop-nodes], in a CLOS network
   the advertisement only needs to be "link-local", i.e., a receiving
   router does not need to re-advertise it further and the mechanism in
   this document does not consider re-advertisement.  In an arbitrary
   topology, to achieve coordinated load-balancing the information may
   need to be advertised further but that is outside the scope of this
   document.

   In some scenarios, a large amount of information may need to be
   advertised, and in some scenarios, the receiving router may not need
   to be directly connected.

   While an IGP, if used for the CLOS network, may also be used to
   advertise the information using link-local flooding scope, it may not
   be a good fit when the information needs to be advertised and
   processed very rapidly not for routing purposes.

   Therefore, UDP is chosen as the transport mechanism.  An
   implementation may advertise and process the UDP messages in the
   forwarding path for timely responses.

   This document does not suggest or restrict when and/or how frequently
   the information is advertised - it is an operational consideration on
   how frequent the advertisements need to be and whether the routers
   can handle that.

   Fragmentation may be used if the delay related to the fragmentation/
   reassembly is not a concern.  Multiple UDP messages may be used to
   advertise pieces of all the information, whether fragmentation is
   used or not.

   This document/revision only specifies the message format.  How the
   information is maintained and used on the receiving router are
   outside the scope of this document/revision but may be added in
   future revisions.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Specification

   The message format is defined as follows:






Zhang, et al.             Expires 22 March 2025                 [Page 3]

Internet-Draft       Advertising Router Information       September 2024


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        UDP source port        |   UDP destination port TBD1   |
     +-------------------------------+-------------------------------+
     |           UDP length          |          UDP Checksum         |
     +-----------------------------+-+-------------------------------+
     |Version|R|R|R|R|    Flags    |A|
     +---------------+-------------+-+-------------------------------+
     |   Auth Type   |   Auth Len    |           Auth Data ...       ~
     +---------------+---------------+-------------------------------+
     |                       Source Router ID                        |
     +---------------------------------------------------------------+
     |                            Link ID                            |
     +---------------------------------------------------------------+
     |                        Sequence Number                        |
     +---------------------------------------------------------------+
     |                        (Repeated) TLVs                        ~
     ~                                                               |
     +---------------------------------------------------------------+

   The IP destination address in the outer IP header is typically an
   IPv4 "All Routers on this Subnet" multicast address (referred to as a
   link-local multicast address), an IPv6 Node-local All Routers Address
   (multicast) [RFC4291], a non-link/node-local multicast address, or a
   local/remote unicast address discovered by means outside the scope of
   this document.

   The 4-bit Version field is for potential future extensions that
   cannot be achieved through additional TLV types.  The current version
   is 0.

   The four R-bits are reserved - they MUST be 0 upon transission and
   MUST be ignored upon receiving.

   The 1-octet Flags field currently has one A-flag defined.  If it is
   set, the (Auth Type, Auth Len, Auth Data) tuple immediately follows
   the Flags field.  If it is not set, the tuple is not present.  The
   details of the tuple are as specified in [RFC5880] and not repeated
   here.

   When the flooding happens on a local link, the Link ID field
   identified the flooding link.  The value could be one of the
   following:

   *  An IPv4 interface address advertised by OSPFv2/ISIS [RFC2328]
      [RFC1195]




Zhang, et al.             Expires 22 March 2025                 [Page 4]

Internet-Draft       Advertising Router Information       September 2024


   *  An Interface ID advertised by OSPFv3 [RFC5340], or by OSPFv2 for
      an unnumbered interface

   *  A Link Local Identifier advertised by OSPFv2/ISIS for GMPLS
      [RFC4203] [RFC4205]

   In this case, the destination address MUST be a link/node-local
   multicast address or a receiver's unicast address on the local link
   and the TTL MUST be 1.  The source address MUST be the local
   interface address for a numbered interface, or a loopback address in
   case of an unnumbered interface.

   If the flooding is to one or more remote receivers, the Link ID MUST
   be set to 0, the destination address MUST be a remote unicast/
   multicast address, the source address MUST be a loopback address, and
   the TTL MUST be set to an appropriate value to ensure its delivery.
   The security consideration will be added in a future revision of this
   document.

   The following TLVs are defined to allow maximum packing.  If
   additional information needs to be advertised, new TLVs may be
   defined without using sub-TLVs to allow efficient encoding of
   additional information, or with sub-TLVs to allow flexibility but at
   the cost of processing complexity.

2.1.  Neighbor Path Information

   This TLV is used when the path information is at per-neighbor level.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   (Type) 1    |               Length          |S| Refresh Rate|
     +-------------------------------+-------------------------------+
     ~                   repeated per-Neighbor Records               |
     +---------------------------------------------------------------+

   The Length field is two-octet.  The Value part starts with a one-
   octet Refresh Rate field, which is followed by repeated per-Neighbor
   Records.  The number of records is derived from the Length field.

   The Refresh Rate field's leftmost bit S denotes the unit of the rate.
   If it is set, the rate is in deciseconds (100ms).  If it is not set,
   the rate is in milliseconds.

   The per-Neighbor record has the following format:





Zhang, et al.             Expires 22 March 2025                 [Page 5]

Internet-Draft       Advertising Router Information       September 2024


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Neighbor ID                                 |
     +---------------+-----------------------------------------------+
     | encoded info  |
     +---------------+

   Neighbor ID: The 4-octet Neighbor ID identifies (the path to) a
   neighbor that is discovered by means outside the scope of this
   document.  It MAY be a BGP-ID described in
   [I-D.wang-idr-next-next-hop-nodes] or some other identifiers that are
   unique in the domain where the signaling is used.  The neighbor can
   be reached via ECMP, e.g., a set of links but the nature is outside
   the scope of this document.

   encoded info: The 1-octet field following the 4-octet Neighbor ID
   field which encodes the information of the path to the neighbor.The
   following encoded info are defined:
































Zhang, et al.             Expires 22 March 2025                 [Page 6]

Internet-Draft       Advertising Router Information       September 2024


     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |R|R|R|U|Quality|
    +---------------+

    where:

    U-Flag:  State Flag. If it is set, the path to the neighbor is UP.
       If it is not set, the path to the neighbor is DOWN.

    The three R-bits:  Reserved. They MUST be 0 upon transission and
       MUST be ignored upon receiving.

    Quality Level: The 4-bit Quality field is used for path quality.
       The value range is from 0 to 15.
       The quality level can be customized, with the lower the level,
       the poorer the path quality.The quality level can be calculated
       based on the current bandwidth and the utilization of the
       forwarding buffer. Bandwidth and buffer use a certain ratio
       to calculate the quality level. The exact method for
       calculating the quality level is beyond the scope of this
       document, but must ensure that the calculation rules are
       consistent among the routers the information is flooded to/from.

       For instance, a 400G interface can be divided into sixteen
       quality levels based on bandwidth utilization, with each level
       representing 25G of bandwidth usage. When the Quality level is 0,
       the available bandwidth is up to 25G. When the Quality Level
       is 15, the available bandwidth is up to 400G.

2.2.  Link Information

   This TLV is used when the information is at per-link level.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   (Type) 3    |                   Length      |S| Refresh Rate|
     +---------------+-------------------------------+-+-------------+
     |              repeated per-link Records                        |
     +---------------------------------------------------------------+

   The value part is repeated records of the following.  The number of
   records is derived from the Length field.







Zhang, et al.             Expires 22 March 2025                 [Page 7]

Internet-Draft       Advertising Router Information       September 2024


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Link ID                                |
     +---------------+-----------------------------------------------+
     | encoded info  |
     +---------------+

   The Link ID is as described earlier.

   encoded info: The 1-octet field following the 4-octet Link ID field
   which encodes the information of the link.  It is encoded exactly the
   same as in the neighbor case.

2.3.  Refreshing and Aging

   The sender MUST re-advertise the information when there is a change,
   and MUST re-fresh previous advertisements at the advertised Refresh
   Rate even when there is no change.

   The receiver MUST age out the received information if it does not
   receive a refresh within a period of three times of the refresh rate.
   Each time an advertisement for a neighbor is received, the aging
   timer is reset according to the latest Refresh Rate.

   The sender MAY adjust the Refresh Rate on its own or based on
   notification from a receiver (Section 2.4).  For example, if the
   information does not change often, a sender may move to a larger
   (slower) Refresh Rate.

   The aging, refreshing and adjustment of the refresh rate are all at
   the per-neighbor/link level.  Neighbors/links whose Refresh Rates are
   the same SHOULD be packed in the same TLV, but MAY be put into
   different TLVs and messages due to MTU limitations and/or
   fragmentation concerns.  Neighbors/links whose Refresh Rates are
   different MUST be put into different TLVs.

   The same information MAY be sent out of different links or to
   different set of receivers with different rates.

2.4.  Refresh Rate Negotiation

   A receiver SHOULD send notifications to the sender if it can not keep
   up with the sender, using a Notification TLV of Type 4:







Zhang, et al.             Expires 22 March 2025                 [Page 8]

Internet-Draft       Advertising Router Information       September 2024


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   (Type) 4    |              Length           |     Value     ~
     +---------------+-------------------------------+---------------+
     ~                        (continued) Value                      |
     +---------------------------------------------------------------+

   The Value part includes sub-TLVs, whose Types share the same space as
   the top level TLVs.

   When sending a notification to a remote node or from an unnumbered
   interface, a loopback address MUST be used as the source address.
   Otherwise, the local interface address SHOULD be used as the source
   address.  The destination address MUST be set to the source address
   in the received flooding packet for which the notification is.

   To notify the sender the desired Refresh Rate for a certain
   advertisement, the corresponding TLV (e.g., the Neighbor Path
   Information TLV) is included as a sub-TLV, and no per-Neighbor/Link
   records are included.  The Refresh Rate field along with the S-flag
   are set to indicate the desired rate.  The Length of the sub-TLV is
   set accordingly.

   While a typical physical link is point-to-point even in the Ethernet
   case, there may be multiple receivers of an advertisement sent out of
   a link (e.g., in the case of LAN) or sent to a group of remote
   receivers via multicast.  If multiple notifications of Refresh Rate
   are received for an advertisement, the largest requested rate MUST be
   used by the sender.

   Consider that a router advertises to a link the information about
   some neighbor/link set S1 at rate R1 and the information about some
   other neighbor/link set S2 at rate R2 where R1 < R2, i.e., the S2
   information is advertised less frequently.  A receiver on the link
   sends back a notification with rate R3 where R1 < R3 < R2.  Then this
   router MUST use R3 as the refresh rate for S1 and R2 as the refresh
   rate for S2.

2.5.  Flow Redirection

   It may be desired for a router to request its upstream to redirect a
   specific flow away from it.  This is done via Flow Redirection TLV:








Zhang, et al.             Expires 22 March 2025                 [Page 9]

Internet-Draft       Advertising Router Information       September 2024


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   (Type) 6/7  |              Length           |S| Refresh Rate|
     +-------------------------------+-------------------------------+
     |    Protocol   |
     +-------------------------------+-------------------------------+
     |           Source Address (4 or 16 otets)                      ~
     +-------------------------------+-------------------------------+
     |           Destination Address (4 or 16 otets)                 ~
     +-------------------------------+-------------------------------+
     |          Source Port          |      Destination Port         |
     +-------------------------------+-------------------------------+
     |                Repeated 5-Tuple Information                   ~
     +-------------------------------+-------------------------------+

   The Type is 6 for IPv4 flows or 7 for IPv6 flows.  The Value field
   encodes one or more 5-tuple records that identify flows by (Protocol,
   Source Address, Destination Address, Source Port, Destination Port).
   The number of records is derived from the Type and Length fields.

3.  Security Considerations

   To be added.

4.  IANA Considerations

   This document requests IANA to allocate a UDP port number TBD1 from
   the User Ports range of the Service Name and Transport Protocol Port
   Number Registry.

   This document requests IANA to create a Router Information TLV Type
   registry with the following initial allocations:

     Type Value         Type Name
     ==========         =========
     0                  Reserved
     1                  Neighbor Path Information
     3                  Link Information
     4                  Notification
     6                  IPv4 Flow Redirection
     7                  IPv6 Flow Redirection

5.  Acknowledgments

   The authors thank Jeffrey Haas and Michal Styszynski for their
   review, comments and suggestions to make this document and solution
   more complete.



Zhang, et al.             Expires 22 March 2025                [Page 10]

Internet-Draft       Advertising Router Information       September 2024


6.  References

6.1.  Normative References

   [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>.

   [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>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [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>.

6.2.  Informative References

   [I-D.cheng-rtgwg-adaptive-routing-framework]
              Cheng, W., Lin, C., Wang, K., and J. Ye, "Adaptive Routing
              Framework", Work in Progress, Internet-Draft, draft-cheng-
              rtgwg-adaptive-routing-framework-02, 21 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-cheng-rtgwg-
              adaptive-routing-framework-02>.

   [I-D.liu-rtgwg-path-aware-remote-protection]
              Liu, Y., Lin, C., Chen, M., and Z. Zhang, "Path-aware
              Remote Protection Framework", Work in Progress, Internet-
              Draft, draft-liu-rtgwg-path-aware-remote-protection-01, 3
              March 2024, <https://datatracker.ietf.org/doc/html/draft-
              liu-rtgwg-path-aware-remote-protection-01>.

   [I-D.wang-idr-next-next-hop-nodes]
              Wang, K., Haas, J., and C. Lin, "BGP Next-next Hop Nodes",
              Work in Progress, Internet-Draft, draft-wang-idr-next-
              next-hop-nodes-01, 4 September 2024,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              wang-idr-next-next-hop-nodes/>.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <https://www.rfc-editor.org/info/rfc1195>.




Zhang, et al.             Expires 22 March 2025                [Page 11]

Internet-Draft       Advertising Router Information       September 2024


   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [RFC4203]  Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
              Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
              <https://www.rfc-editor.org/info/rfc4203>.

   [RFC4205]  Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate
              System to Intermediate System (IS-IS) Extensions in
              Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4205, DOI 10.17487/RFC4205, October 2005,
              <https://www.rfc-editor.org/info/rfc4205>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <https://www.rfc-editor.org/info/rfc5340>.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net


   Kevin F. Wang
   Juniper Networks
   Email: kfwang@juniper.net


   Changwang Lin
   New H3C Technologies
   Email: linchangwang.04414@h3c.com


   Niranjan Vaidya
   Broadcom
   Email: niranjan.vaidya@broadcom.com












Zhang, et al.             Expires 22 March 2025                [Page 12]