<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="exp" docName="draft-chen-ospf-ias-lk-13" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="inter-as-te-link">OSPF Extensions for Broadcast Inter-AS TE Link</title>
    <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street> </street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>hchen.ietf@gmail.com</email>
      </address>
    </author>

 <author initials="M" fullname="Mehmet Toy" 
            surname="Toy">
      <organization>Verizon</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region> </region>
          <code> </code>
          <country>USA</country>
        </postal>
        <email>mehmet.toy@verizon.com</email>
      </address>
 </author>

   <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>Alef Edge</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region> </region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

 <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

  <author fullname="Zhenqiang Li" initials="Z" surname="Li">
    	<organization>China Mobile</organization>
    	<address>
        <postal>
          <street>No.32 Xuanwumenxi Ave., Xicheng District</street>
          <city>Beijing</city>
          <code>100032</code>
          <country>P.R. China</country>
        </postal>
        <email>li_zhenqiang@hotmail.com</email>
      </address>
    </author>


 <author initials="Y" fullname="Yi Yang" 
            surname="Yang">
      <organization>IBM</organization>

      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region>NC</region>
          <code> </code>
          <country>USA</country>
        </postal>
        <email>yyang1998@gmail.com</email>
        <!-- <email>yiya@cisco.com</email> -->
      </address>
    </author>


    <date year="2024" />
    <area>Routing</area>
    <workgroup>OSPF Working Group</workgroup> 

<abstract>
<t>
This document presents extensions to 
the Open Shortest Path First (OSPF) 
for advertising broadcast inter-AS Traffic Engineering (TE) links.
</t>
</abstract>

  </front>
  <middle>

    <section title="Introduction" toc="default">


    <t>Connections among different Autonomous Systems (ASes) may be 
point-to-point (P2P) links and broadcast links.  
For a P2P inter-AS TE link,
RFC 5392 defines a new Opaque LSA, the Inter-AS-TE-v2 LSA, 
for advertising the OSPFv2 link; and
a new OSPFv3 LS type, Inter-AS-TE-v3 LSA, 
for advertising the OSPFv3 link.

</t>

    <t>Both the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA 
contain one top level TLV:
    <list style="hanging">
       <t hangText=" 2 - "> Link TLV</t>
    </list>
The Link TLV describes a single link and includes a set of sub-TLVs.
</t>

    <t>The Link ID sub-TLV defined in RFC 3630 MUST NOT 
be used in the Link TLV of an Inter-AS-TE-v2 LSA, 
and the Neighbor ID sub-TLV defined in RFC 5329 MUST NOT
be used in the Link TLV of an Inter-AS-TE-v3 LSA.
</t>

    <t>Instead, the remote ASBR is identified by the inclusion
of Remote AS Number sub-TLV and 
IPv4/IPv6 Remote ASBR ID sub-TLV, which is defined in RFC 5392.
</t>

    <t>For a P2P inter-AS link, the information about 
its remote ASBR for replacing its link ID may be configured. 
For a broadcast inter-AS link, 
its link ID is the interface IP address of the designated router (DR)
of the link in OSPF. 
Since no OSPF runs over any broadcast inter-AS link,
no DR or backup DR (BDR) is selected. 
It is hard to configure a replacement for DR and BDR. 
</t>
     
    <t>This document presents extensions to OSPF 
for advertising broadcast inter-AS TE links through
defining a new sub-TLV for a broadcast link 
without configuring any replacement for DR and BDR on the link. 
</t>


    </section>


    <section title="Conventions Used in This Document" toc="default">
        <t>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 <xref target="RFC2119"/>.</t>
    </section>
 


    <section title="Information on Inter-AS TE Link" toc="default"> 

    <t>For a broadcast link connecting multiple ASBRs 
in a number of ASes, 
on each of the ASBRs X, the following information about the link 
may be obtained:
<figure>
  <artwork> <![CDATA[ 
  1)  Link Type: Multi-access
  2)  Local IP address with mask length
  3)  Traffic engineering metric
  4)  Maximum bandwidth 
  5)  Maximum reservable bandwidth 
  6)  Unreserved bandwidth 
  7)  Administrative group 
  8)  SRLG
  ]]>
  </artwork>
</figure>
No remote IP address or link ID (i.e., DR's interface address) 
may be obtained.
</t>

    </section>



    <section title="Extensions to OSPF" toc="default"> 


    <section title="sub-TLVs" toc="default">

    <t>Two new sub-TLVs are defined. 
One is for local IPv4 address with mask length; and 
the other is for local IPv6 address with mask length.
</t>
     <t>The format of the sub-TLV for a local IPv4 address with
mask length is shown as follows.
<figure>
  <artwork> <![CDATA[
   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 (stTBD1)         |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    IPv4 Address (4 bytes)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Mask Length  |
  +-+-+-+-+-+-+-+-+
  ]]>
  </artwork>
</figure>
The IPv4 Address indicates the local IPv4 address of a link.
The Mask Length indicates the length of the IPv4 address mask.
</t>

     <t>The format of the sub-TLV for a local IPv6 address with
mask length is illustrated below.
<figure>
  <artwork> <![CDATA[
   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 (stTBD2)          |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     IPv6 Address (16 bytes)                   |
  ~                                                               ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Mask Length  |
  +-+-+-+-+-+-+-+-+
  ]]>
  </artwork>
</figure>
The IPv6 Address indicates the local IPv6 address of a link.
The Mask Length indicates the length of the IPv6 address mask.
</t>

</section>


    <section title="Procedures" toc="default"> 

    <section title="OSPF Router Procedure" toc="default"> 

    <t>For a broadcast inter-AS link connecting to multiple ASBRs, 
each of the ASBRs as an OSPF router advertises 
an LSA (Inter-AS-TE-v2 LSA for OSPFv2 or Inter-AS-TE-v3 LSA for OSPFv3) 
with a link TLV containing sub-TLVs for 
the information such as 1) 10 8) on the broadcast link 
described in Section 3.
</t>

    <t>When TE is enabled on an inter-AS link and the link is up, 
the ASBR SHOULD advertise this link using the normal procedures for 
OSPF-TE. When either the link is down or TE is disabled on the
link, the ASBR SHOULD withdraw the advertisement. When there are
changes to the TE parameters for the link (for example, when the
available bandwidth changes), the ASBR SHOULD re-advertise the link
but MUST take precautions against excessive re-advertisements.
</t>
    </section> 

    <section title="Super Node Procedure" toc="default"> 

    <t>Suppose that there is a super node, 
which just receives LSAs from each of ASes (or domains)
through a passive OSPF adjacency between the super node and
an ASBR or ABR in the AS or domain. 
</t>

    <t>For a new broadcast link connecting multiple routers with no link ID
configured, when the super node receives an LSA containing the link 
attached to router X, it stores the link from X into its TED.  
It finds the link's remote end P
using the link's local IP address with network mask. P is a Pseudo
node identified by the local IP address of the DR
selected from the routers connected to the link. After finding P, it
associates the link attached to X with P and 
the link connected to P with X. 
If P is not found, a new Pseudo node P is created.
The super node associates the link attached to X with P and 
the link attached to P with X.
This creates a bidirectional connection between X and P.
</t>

    <t>The first router and second router from which the super node receives 
an LSA containing the link are selected as the DR and 
BDR respectively. After the DR is down, the
BDR node becomes the DR and the router other
than the DR with the largest (or smallest) local IP address connecting
to the link is selected as the BDR.
</t>

    <t>When the old DR is down and the BDR
becomes the new DR, the super node updates its TED through
removing the link between each of routers X and old P (the Pseudo node
corresponding to the old DR) and adding a link between
each of routers X (still connecting to the broadcast link) and new P
(the Pseudo node corresponding to the new DR).
</t>
</section>
</section>

</section>
 


    <section title="Security Considerations" toc="default">
    <t> The mechanism described in this document does not raise any new security issues for the OSPF protocols.</t>
    </section>


    <section title="IANA Considerations" toc="default">
      <t>This section specifies requests for IANA allocation.</t>
    </section>
    
    
    <section title="Acknowledgement" toc="default">
      <t>The authors would like to thank all 
for their valuable comments on this draft.</t>
    </section>


  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml" ?>
    <?rfc include="reference.RFC.5392.xml" ?>
    <?rfc include="reference.RFC.5329.xml" ?>
    <?rfc include="reference.RFC.3630.xml" ?>

    </references>
    <references title="Informative References">
      <?rfc include="reference.RFC.6805.xml" ?>
<!--
      <?rfc include="reference.RFC.7752.xml" ?>
-->
       
    </references>


  </back>
</rfc>