<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<?rfc strict="yes"?>

<rfc category="std"
    docName="draft-hares-deprecate-atomic-aggregate-00.txt "
    updates="4271"
    ipr="pre5378Trust200902">
    <front>
	<title abbrev="Deprecate Atomic Aggregate">Decprecate Atomic Aggregate  </title>
    <author fullname="Susan Hares" initials="S" surname="Hares">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>7453 Hickory Hill</street>
          <city>Saline</city>
          <region>MI</region>
          <code>48176</code>
          <country>USA</country>
        </postal>
        <email>shares@ndzh.com</email>
      </address>
	</author>
 

        <date />

        <area>Routing</area>
        <workgroup>IDR</workgroup>
        <keyword>BGP</keyword>
        <keyword>cease</keyword>
        <keyword>shutdown</keyword>

        <abstract>
            <t>
                This document deprecates the support for the BGP well-know discretionary attribute 
				ATOMIC_AGGREGATE specified in RFC4271.  It proposes the changes to RFC4271 to 
				remove its support. 
		   </t> 
        </abstract>

    <note title="Requirements Language">
        <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>
    </note>

    </front>

    <middle>
        <section anchor="intro" title="Introduction">
            <t>
                The ATOMIC_AGGREGATE well-known discretionary attribute is specified 
                in <xref target="RFC4271"></xref> in section 5.1.6. This document 
				specifies the changes to RFC4271 in order to remove the ATOMIC_AGGREGATE 
				attribute. 
            </t>
			<t> 
			</t>
        </section>
		<section title="Changes to Section 4.3">
		<t> delete the following text: 
		</t>
		<t>
		<figure>
		<artwork>
		 
         f) ATOMIC_AGGREGATE (Type Code 6)

            ATOMIC_AGGREGATE is a well-known discretionary attribute of
            length 0.

            Usage of this attribute is defined in 5.1.6.
		</artwork>
		</figure>
		</t>
		</section>

        <section title="Changes to Section 5 - Path Attributes ">
         <t>1: Section 5.0 should have the following changes (p. 24)
		 </t>
		 <t>Old: 
		 <figure>
		 <artwork>
		 attribute           EBGP                    IBGP
         ORIGIN             mandatory               mandatory
         AS_PATH            mandatory               mandatory
         NEXT_HOP           mandatory               mandatory
         MULTI_EXIT_DISC    discretionary           discretionary
         LOCAL_PREF         see Section 5.1.5       required
         ATOMIC_AGGREGATE   see Section 5.1.6 and 9.1.4
         AGGREGATOR         discretionary           discretionary
		 </artwork>
		 </figure>
		 </t>
		 <t>New:
		 <figure>
		 <artwork>
		 attribute           EBGP                    IBGP
         ORIGIN             mandatory               mandatory
         AS_PATH            mandatory               mandatory
         NEXT_HOP           mandatory               mandatory
         MULTI_EXIT_DISC    discretionary           discretionary
         LOCAL_PREF         see Section 5.1.5       required
         AGGREGATOR         discretionary           discretionary
		 </artwork>
		 </figure>
		 </t>
		 <t> 
		 2: Delete Section 5.1.6 
		 </t>
		 </section> 
		 <section title="Changes to Section 9">
		 <section title="Changes to section 9.1.4">
		 <t>3: Changes to section 9.1.4 
		 </t>
		 <t>Old: 
         </t>
		 <t>
		  If a BGP speaker chooses to aggregate, then it SHOULD either include
		  all ASes used to form the aggregate in an AS_SET, or add the
          ATOMIC_AGGREGATE attribute to the route.
         </t>
		 <t>New
		 </t>
		 <t>
		 If a BGP speaker chooses to aggregate, then it SHOULD either include
		  all ASes used to form the aggregate in an AS_SET. 
		 </t>
		 <t>delete the following text:
		 </t>
		 <t>"In particular, a route that carries the
		ATOMIC_AGGREGATE attribute MUST NOT be de-aggregated."
		 </t>
        </section>
		<section title="Section 9.2 Changes">
		<t>Text to delete: 
		</t>
		<t>
		<figure>
		<artwork>
	    ATOMIC_AGGREGATE:
         If at least one of the routes to be aggregated has
         ATOMIC_AGGREGATE path attribute, then the aggregated route
         SHALL have this attribute as well.
		</artwork>
		</figure>
		</t>
		</section>
		</section> 
		<section anchor="ops" title="Operational Considerations">
            <t>Input needed here. 
			</t> 
        </section>

        <section anchor="error" title="Error Handling">
            <t>
              An ATOMIC_AGGREGATE  attribute received should be silently ignored. 
            </t>
        </section>

        <section anchor="iana" title="IANA Considerations">
            <t>
			IANA Is asked to deprecate the BGP Attribute: 
			Atomic_Aggregate with this document as reference. 
            </t>
        </section>

        <section anchor="security" title="Security Considerations">
            <t>
                Deprecating a BGP attribute does not change the 
				BGP messages sent on over a secure transport. 
            </t>
            <t>
                Users of this mechanism should be aware that unless a
                transport that provides integrity (such as <xref
                target="RFC5925">TCP-AO</xref>) is used for the BGP
                session in question, BGP Attributes can be forged. 
                This could become an attack vector. 
				</t>
				<t>
				Unless a transport that provides
                confidentiality (such as <xref
                target="RFC4303">IPSec</xref>) is used, BGP attributes 		
                Communication messages could be snooped by an attacker  
				allowing access to BGP attributes. 
                These issues are common to any BGP message but may be of
                greater interest in the context of this proposal since
                a BGP Attribute is being deleted. 
            </t>                
        </section>

 
    </middle>

    <back>

        <references title="Normative References">
            <?rfc include="reference.RFC.2119"?>
            <?rfc include="reference.RFC.4271"?>
			<?rfc include="reference.RFC.4303"?>
			<?rfc include="reference.RFC.5925"?>
        </references>

        <section anchor="acknowledgements" title="Acknowledgements">
            <t>
                The author would like to gratefully acknowledge  
				the IDR WG discussion
            </t>
        </section>
    </back>

</rfc>
