Internet DRAFT - draft-chen-savnet-lsr-intra

draft-chen-savnet-lsr-intra







Network Working Group                                            H. Chen
Internet-Draft                                                 Futurewei
Intended status: Standards Track                                W. Cheng
Expires: 4 August 2024                                      China Mobile
                                                                 A. Wang
                                                           China Telecom
                                                               G. Mishra
                                                            Verizon Inc.
                                                                  Y. Fan
                                                            Casa Systems
                                                                  X. Liu
                                                               Alef Edge
                                                         1 February 2024


                  IGP Extensions for Intra-Domain SAV
                     draft-chen-savnet-lsr-intra-02

Abstract

   This document specifies extensions to OSPF and IS-IS for Source
   Address Validation in Intra-domain.

Requirements Language

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

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 4 August 2024.





Chen, et al.              Expires 4 August 2024                 [Page 1]

Internet-Draft              IGP for Intra SAV              February 2024


Copyright Notice

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

   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.  Overview of Intra-Domain SAV  . . . . . . . . . . . . . . . .   3
     2.1.  SAV Table and its Usage . . . . . . . . . . . . . . . . .   3
     2.2.  Intra-Area SAV  . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Inter-Area SAV  . . . . . . . . . . . . . . . . . . . . .   5
   3.  Extensions to IGP . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Extensions to OSPFv2  . . . . . . . . . . . . . . . . . .   6
       3.1.1.  Indicating Prefixes to be Validated . . . . . . . . .   7
       3.1.2.  Path Cost from Prefix to ABR  . . . . . . . . . . . .   7
     3.2.  Extensions to OSPFv3  . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Indicating Prefixes to be Validated . . . . . . . . .   7
       3.2.2.  Path Cost from Prefix to ABR  . . . . . . . . . . . .   8
     3.3.  Extensions to IS-IS . . . . . . . . . . . . . . . . . . .   8
       3.3.1.  Indicating Prefixes to be Validated . . . . . . . . .   8
       3.3.2.  Path Cost from Prefix to ABR  . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  OSPFv2  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  OSPFv3  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Requirements for intra-domain Source Address Validation (SAV)
   Mechanisms are described in
   [I-D.ietf-savnet-intra-domain-problem-statement].  The most important
   requirements include:



Chen, et al.              Expires 4 August 2024                 [Page 2]

Internet-Draft              IGP for Intra SAV              February 2024


   *  Accurate Validation,

   *  Fast Convergence of SAV table/rules on dynamic routing changes,
      and

   *  Backward Compatible (i.e., Working in Incremental/Partial
      Deployment).

   This document proposes IGP (i.e., OSPF and IS-IS) extensions for
   Intra-Domain SAV to meet these requirements.

2.  Overview of Intra-Domain SAV

   This section briefs SAV table and its usage, and then introduces one
   area (i.e., intra-area) SAV and multiple areas (i.e., inter-area)
   SAV.

2.1.  SAV Table and its Usage

   Every node (i.e., IGP control plane on the node) in a Autonomous
   System (AS) builds and maintains its own Source Address Validation
   (SAV) Table based on its Link-State Database (LSDB).  The format of a
   SAV table is shown in Figure 1.

       +==========+============+     +===========+================+
       |Source    |Incoming    |     |Destination|Outgoing        |
       |Prefix    |Interface   |     |Prefix     |Interface       |
       +==========+============+     +===========+================+
       |S-prefix-1|Interface-a |     |D-prefix-1 |Out-interface-a |
       +----------+------------+     +-----------+----------------+
   ==> |S-prefix-2|Interface-b | ==> |D-prefix-2 |Out-interface-b | ==>
    ^  +----------+------------+  ^  +-----------+----------------+  ^
    |     ...                     |      ...                         |
    |  +----------+------------+  |  +-----------+----------------+  |
    |  |S-prefix-n|Interface-x |  |  |D-prefix-n |Out-interface-x |  |
    |  +----------+------------+  |  +-----------+----------------+  |
    |   Format of SAV Table       |             FIB                  |
    |                             |                                  |
   Packet in                  forward Packet                  Packet out
                  if source address and receiving interface
                  of Packet in SAV Table

                   Figure 1: Format of SAV Table and FIB

   When there is a shortest path from source prefix S-prefix-i to a
   destination through node N and interface Interface-j of node N, the
   SAV table of node N has a row containing S-prefix-i as Source Prefix
   and Interface-j as Incoming Interface.  For example, the first row in



Chen, et al.              Expires 4 August 2024                 [Page 3]

Internet-Draft              IGP for Intra SAV              February 2024


   the SAV table of node N contains S-prefix-1 as Source Address and
   Interface-a as Incoming Interface.  This row indicates that there is
   a shortest path from S-prefix-1 to a destination through node N and
   Interface-a of node N.

   The SAV table is sent to the data plane and used to validate the
   source address of a packet.  When receiving a packet from an
   interface, the node validates the packet using its SAV table.

   If the source address of the packet and the receiving/incoming
   interface are in the SAV table (i.e., there is one row in the SAV
   table containing the source address and the receiving/incoming
   interface), the packet is forwarded according to the FIB and
   destination address of the packet as shown in the figure; otherwise
   (i.e., there is no row in the SAV table containing the source address
   and the receiving/incoming interface), the packet is blocked or
   dropped.

2.2.  Intra-Area SAV

   This section introduces a method for a node to build its SAV table in
   a special case where an AS has only one area or SAV is for only one
   area.

   When every routing/forwarding path in an AS is symmetric (i.e., every
   path has the same cost in both directions), every node in the AS
   builds and maintains its SAV table using its RIB/FIB.  The node can
   determine whether every path is symmetric by checking its LSDB.  If
   every link in its LSDB is symmetric (i.e., has the same metric or
   cost in both directions), then every path is symmetric; otherwise
   (i.e., there is an asymmetric link, its metric/cost in one direction
   is different from the one in the other/reverse direction), there are
   some asymmetric paths.

   The node builds its SAV table using the RIB/FIB by including a row in
   its SAV table for each prefix with a next hop interface in its RIB/
   FIB.  The row contains the prefix and the interface in the Source
   Prefix and Incoming Interface columns respectively.

   When there is a routing/forwarding path which is not symmetric, every
   node X builds its SAV table in the following steps:

   1.  Builds reverse shortest path tree (RSPT).  Node X computes/builds
       a shortest path tree from node X to the other nodes using the
       link metric or cost of each link in the reverse direction.






Chen, et al.              Expires 4 August 2024                 [Page 4]

Internet-Draft              IGP for Intra SAV              February 2024


   2.  Builds reverse routing table (RRT) using RSPT.  When node X finds
       a shortest path from node X to node Y with a next hop interface
       in its RSPT, node X adds an entry for each prefix attached to Y
       into its RRT.  The entry has the prefix as the destination and
       the next hop interface as the next hop.

   3.  Builds SAV table using RRT.  Node X includes a row in its SAV
       table for each prefix with a next hop interface in its RRT.  The
       row contains the prefix and the interface in the Source Prefix
       and Incoming Interface columns respectively.

   There are a few options below for the scope of the prefixes to be
   validated.

   Option 1:  The prefixes attached to every node.

   Option 2:  The prefixes attached to each ASBR and ABR.

   Option 3:  The prefixes indicated/configured on any node.

   The method above builds the SAV table for option 1.

   For option 2, we consider only ASBR and ABR Y in step 2.  Thus the
   RRT contains only the prefixes attached to ASBRs and ABRs.  So does
   the SAV table.

   For option 3, we consider only the prefixes attached to node Y and
   indicated/configured by node Y in step 2.  Thus the RRT contains only
   these prefixes.  So does the SAV table.

2.3.  Inter-Area SAV

   This section introduces a method for a node to build its SAV table in
   a general case where an AS has multiple areas and SAV is for all the
   areas.  The method is based on the one described in Section 2.2.

   For any area A, every node X in A builds its SAV table using the
   following steps:

   1.  Gets area shortest path tree (ASPT).  The ASPT is a tree from
       node X as root to all the other nodes in area A.  If every link
       in area A is symmetric, the ASPT is the SPT built by node X for
       its RIB, which is reused; otherwise (i.e., there is asymmetric
       link in area A), the ASPT is a RSPT from node X as root to all
       the other nodes in area A.  Node X computes/builds the RSPT as
       described in Section 2.2.





Chen, et al.              Expires 4 August 2024                 [Page 5]

Internet-Draft              IGP for Intra SAV              February 2024


   2.  Extends ASPT.  For each leaf node L of ASPT, node X attaches node
       L of ASPT every prefix of node L if the cost from the prefix to L
       is minimal.  If every link in area A is symmetric and every path
       between any ABR and a summary prefix/address from the ABR is
       symmetric, the extended ASPT is the SPT with the prefixes of each
       node in area A built by node X for its RIB, which is reused.

   3.  Builds reverse routing table (RRT) using extended ASPT.  When
       node X finds a shortest path from node X to node Y with a next
       hop interface in its extended ASPT, node X adds an entry for each
       prefix attached to Y into its RRT.  The entry has the prefix as
       the destination and the next hop interface as the next hop.

   4.  Builds SAV table using RRT.  Node X includes a row in its SAV
       table for each prefix with a next hop interface in its RRT.  The
       row contains the prefix and the interface in the Source Prefix
       and Incoming Interface columns respectively.

   The method above builds the SAV table for option 1.

   For option 2, we consider only ASBR and ABR Y in step 3.  Thus the
   RRT contains only the prefixes attached to ASBRs and ABRs.  So does
   the SAV table.

   For option 3, we consider only the prefixes attached to node Y and
   indicated/configured by node Y in step 3.  Thus the RRT contains only
   these prefixes.  So does the SAV table.

3.  Extensions to IGP

   This section describes extensions to OSPFv2, OSPFv3 and IS-IS for
   SAV.  The extensions include:

   *  A new S-Flag (SAV Prefix Flag) of 1 bit indicating a prefix to be
      validated when option 3 described in Section 2.2 is selected.

   *  A new Sub-TLV, called Reverse Cost to Prefix Sub-TLV, for ABR to
      advertise the cost of the shortest path from the prefix to the ABR
      when the path between the ABR and the prefix is not symmetric
      (i.e., the cost of the shortest path from the ABR to the prefix is
      different from that of the path from the prefix to the ABR).

3.1.  Extensions to OSPFv2








Chen, et al.              Expires 4 August 2024                 [Page 6]

Internet-Draft              IGP for Intra SAV              February 2024


3.1.1.  Indicating Prefixes to be Validated

   [RFC7684] defines the OSPFv2 Extended Prefix TLV to advertise
   additional attributes associated with the prefix.  A new flag of one
   bit in Flags field of the TLV is defined below:

   0x20 - S-Flag (SAV Prefix Flag):  Set when the prefix is configured
          for SAV (i.e., to be validated as a Source Address of a
          packet).

3.1.2.  Path Cost from Prefix to ABR

   [RFC7684] defines the OSPFv2 Extended Prefix TLV.  A new OSPFv2
   Reverse Cost to Prefix Sub-TLV is defined to be included in this TLV
   with Route Type 3 (Inter-Area).  It has the following format:

       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 (TBD1)       |          Length (4)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Cost from Prefix to ABR                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: OSPFv2 Reverse Cost to Prefix Sub-TLV

3.2.  Extensions to OSPFv3

3.2.1.  Indicating Prefixes to be Validated

   [RFC8362] defines Intra-Area-Prefix TLV and External-Prefix TLV to
   advertise additional attributes associated with the prefix.  A new
   Sub-TLV called Prefix Attribute Flags Sub-TLV is defined to be
   included in these two TLVs.  It has the following format:

       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 (TBD2)       |          Length (4)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Prefix Attribute Flags                 |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: OSPFv3 Prefix Attribute Flags Sub-TLV

   One flag of 1-bit in Prefix Attribute Flags field is defined below:

   0x01 - S-Flag (SAV Prefix Flag):  Set when the prefix is configured



Chen, et al.              Expires 4 August 2024                 [Page 7]

Internet-Draft              IGP for Intra SAV              February 2024


          for SAV (i.e., to be validated as a Source Address of a
          packet).

3.2.2.  Path Cost from Prefix to ABR

   [RFC8362] defines the Intra-Area-Prefix TLV.  A new OSPFv3 Reverse
   Cost to Prefix Sub-TLV is defined to be included in this TLV.  It has
   the following format:

       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 (TBD3)       |          Length (4)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Cost from Prefix to ABR                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: OSPFv3 Reverse Cost to Prefix Sub-TLV

3.3.  Extensions to IS-IS

3.3.1.  Indicating Prefixes to be Validated

   [RFC7794] defines the Prefix Attribute Flags Sub-TLV to advertise
   additional IPv4 and IPv6 prefix attributes in TLV 135 (Extended IP
   Reachability), 235 (MT IP Reach), 236 (IPv6 IP Reach) and 237 (MT
   IPv6 IP Reach).  A new one bit flag in the Sub-TLV is defined below:

   Bit 5 - SAV Prefix Flag (S-flag):  Set when the prefix is configured
          for SAV (i.e., to be validated as a Source Address of a
          packet).

3.3.2.  Path Cost from Prefix to ABR

   A new IS-IS Reverse Cost to Prefix Sub-TLV is defined for an ABR (i.
   e., level 2/1 router) to include it in TLV 135, 235, 236 and 237 for
   the prefix.  It has the following format:

       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 (TBD4)  |   Length (4)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Cost from Prefix to ABR                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 5: IS-IS Reverse Cost to Prefix Sub-TLV




Chen, et al.              Expires 4 August 2024                 [Page 8]

Internet-Draft              IGP for Intra SAV              February 2024


4.  Security Considerations

   TBD.

5.  IANA Considerations

5.1.  OSPFv2

   Under "OSPFv2 Extended Prefix TLV Flags registry", IANA is requested
   to assign a codepoint for SAV Prefix Flag as follows:

   +=======+==========================+=============+
   | Value | Description              |Reference    |
   +=======+==========================+=============+
   | 0x10  | S-Flag (SAV Prefix Flag) |This document|
   +-------+--------------------------+-------------+

   Under "OSPFv2 Extended Prefix TLV Sub-TLVs registry" as defined in
   [RFC7684], IANA is requested to assign a registry value for Link
   Number Sub-TLV as follows:

   +===========+=========================+==================+
   |  Value    | Description             | Reference        |
   +===========+=========================+==================+
   |  TBD1     | Reverse Cost to Prefix  | This document    |
   +-----------+-------------------------+------------------+

5.2.  OSPFv3

   Under "OSPFv3 Extended-LSA Sub-TLVs registry" as defined in
   [RFC8362], IANA is requested to assign a registry value for Reverse
   Cost to Prefix Sub-TLV as follows:

   +===========+=========================+==================+
   |  Value    | Description             | Reference        |
   +===========+=========================+==================+
   |  TBD2     | Prefix Attribute Flags  | This document    |
   +-----------+-------------------------+------------------+
   |  TBD3     | Reverse Cost to Prefix  | This document    |
   +-----------+-------------------------+------------------+

5.3.  IS-IS

   Under "IS-IS Bit Values for Prefix Attribute Flags Sub-TLV", IANA is
   requested to assign a codepoint for SAV Prefix Flag as follows:






Chen, et al.              Expires 4 August 2024                 [Page 9]

Internet-Draft              IGP for Intra SAV              February 2024


   +=====+========================+=============+
   |Bit #|Name                    |Reference    |
   +=====+========================+=============+
   |  5  |SAV Prefix Flag (S-flag)|This document|
   +-----+------------------------+-------------+

   Under "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability", IANA
   is requested to assign a codepoint for Reverse Cost to Prefix Sub-TLV
   as follows:

  +===========================+==+===+===+===+===+===+===+=============+
  |Type|Description           |27|126|127|135|235|236|237|reference    |
  +====+======================+==+===+===+===+===+===+===+=============+
  |TBD3|Reverse Cost to Prefix|n | n | n | y | y | y | y |This document|
  +----+----------------------+--+---+---+---+---+---+---+-------------+

6.  Acknowledgements

   The authors would like to thank Joel Halpern for the valuable
   comments and suggestions on this draft..

7.  References

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

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

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.



Chen, et al.              Expires 4 August 2024                [Page 10]

Internet-Draft              IGP for Intra SAV              February 2024


   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
              2015, <https://www.rfc-editor.org/info/rfc7684>.

   [RFC7794]  Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
              U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
              and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
              March 2016, <https://www.rfc-editor.org/info/rfc7794>.

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

   [RFC8362]  Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
              F. Baker, "OSPFv3 Link State Advertisement (LSA)
              Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
              2018, <https://www.rfc-editor.org/info/rfc8362>.

7.2.  Informative References

   [I-D.ietf-savnet-intra-domain-problem-statement]
              Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source
              Address Validation in Intra-domain Networks Gap Analysis,
              Problem Statement, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-savnet-intra-domain-problem-
              statement-02, 17 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              intra-domain-problem-statement-02>.

   [RFC5250]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
              OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
              July 2008, <https://www.rfc-editor.org/info/rfc5250>.

Authors' Addresses

   Huaimo Chen
   Futurewei
   Boston, MA,
   United States of America
   Email: hchen.ietf@gmail.com


   Weiqiang Cheng
   China Mobile
   China
   Email: chengweiqiang@chinamobile.com




Chen, et al.              Expires 4 August 2024                [Page 11]

Internet-Draft              IGP for Intra SAV              February 2024


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: wangaj3@chinatelecom.cn


   Gyan S. Mishra
   Verizon Inc.
   13101 Columbia Pike
   Silver Spring,  MD 20904
   United States of America
   Phone: 301 502-1347
   Email: gyan.s.mishra@verizon.com


   Yanhe Fan
   Casa Systems
   United States of America
   Email: yfan@casa-systems.com


   Xufeng Liu
   Alef Edge
   United States of America
   Email: xufeng.liu.ietf@gmail.com























Chen, et al.              Expires 4 August 2024                [Page 12]