--- 1/draft-ietf-ospf-xaf-te-02.txt	2018-10-03 11:13:24.689994660 -0700
+++ 2/draft-ietf-ospf-xaf-te-03.txt	2018-10-03 11:13:24.709995144 -0700
@@ -1,21 +1,21 @@
 
 LSR                                                           A. Smirnov
 Internet-Draft                                       Cisco Systems, Inc.
 Updates: 5786 (if approved)                                    A. Retana
 Intended status: Standards Track                          Huawei R&D USA
-Expires: October 20, 2018                                      M. Barnes
+Expires: April 6, 2019                                         M. Barnes
                                                      Cisco Systems, Inc.
-                                                          April 18, 2018
+                                                         October 3, 2018
 
    OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
-                       draft-ietf-ospf-xaf-te-02
+                       draft-ietf-ospf-xaf-te-03
 
 Abstract
 
    When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network
    the Multiprotocol Label Switching (MPLS) TE Label Switched Paths
    (LSP) infrastructure may be duplicated, even if the destination IPv4
    and IPv6 addresses belong to the same remote router.  In order to
    achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be
    computed over MPLS TE tunnels created using information propagated in
    another OSPF instance.  This is solved by advertising cross-address
@@ -32,21 +32,21 @@
    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 October 20, 2018.
+   This Internet-Draft will expire on April 6, 2019.
 
 Copyright Notice
 
    Copyright (c) 2018 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
@@ -58,24 +58,24 @@
 
 Table of Contents
 
    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
    2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
    3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
    4.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .   5
    5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
      8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
 
 1.  Introduction
 
    TE Extensions to OSPFv2 [RFC3630] and to OSPFv3 [RFC5329] have been
    described to support intra-area TE in IPv4 and IPv6 networks,
    respectively.  In both cases the TE database provides a tight
    coupling between the routed protocol and TE signaling information in
    it.  In other words, any use of the TE link state database is limited
    to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340].
 
@@ -246,20 +246,32 @@
       separately.
 
       *  If Node Local Address sub-TLV belongs to the same address
          family as instance of OSPF protocol advertising it then address
          carried in the sub-TLV MUST be treated as described in
          [RFC5786].
 
       *  Otherwise the address is used for X-AF tunnel tail-end mapping
          as defined by this document.
 
+   Only routers that serve as endpoints for one or more TE tunnels MUST
+   be upgraded to support procedures described in this document:
+
+   o  Tunnel tailends need to advertise Node IPv4 Local Address and/or
+      Node IPv6 Local Address sub-TLVs as described in this
+      specification
+
+   o  Tunnel headends need to perform X-AF routing calculation as
+      described in this specification
+
+   Other routers in the network do not need to support X-AF procedures.
+
 5.  Security Considerations
 
    This document introduces no new security concerns.  Security
    considerations of using Node Attribute TLV are discussed in
    [RFC5786].
 
 6.  IANA Considerations
 
    This document has no IANA actions.