Internet DRAFT - draft-ietf-isis-udl
draft-ietf-isis-udl
Networking Working Group L. Ginsberg
Internet-Draft S. Mirtorabi
Intended status: Standards Track S. Previdi
Expires: December 30, 2014 A. Roy
Cisco Systems
June 28, 2014
IS-IS Support for Unidirectional Links
draft-ietf-isis-udl-02.txt
Abstract
This document defines support for the operation of IS-IS over
Unidirectional Links without the use of tunnels or encapsulation of
IS-IS Protocol Data Units. Adjacency establishment when the return
path from the router at the receive end of a unidirectional link to
the router at the transmit end of the unidirectional link is via
another unidirectional link is supported. The extensions defined
here are backwards compatible - only the routers directly connected
to a unidirectional link need to be upgraded.
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 RFC 2119 [RFC2119].
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 http://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 December 30, 2014.
Ginsberg, et al. Expires December 30, 2014 [Page 1]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
Copyright Notice
Copyright (c) 2014 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Encoding Extensions . . . . . . . . . . . . . . . . . . . . 3
2.1. UDL LSPs and the UDL-TLV . . . . . . . . . . . . . . . . 4
2.2. UDL Intermediate System Neighbors sub-TLV . . . . . . . . 4
2.2.1. UDL Point-to-Point Intermediate System Neighbor Sub-
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. UDL LAN Intermediate System Neighbor Sub-TLV . . . . 5
2.2.3. Sub-TLVs Associated w an IS Neighbor . . . . . . . . 6
2.3. UDL Manual Area Addresses sub-TLV . . . . . . . . . . . . 9
3. Adjacency Establishment . . . . . . . . . . . . . . . . . . . 10
3.1. Adjacency Establishment in Point-to-Point Mode . . . . . 10
3.2. Adjacency Establishment in Broadcast Mode . . . . . . . . 11
3.3. UDL link metric configuration . . . . . . . . . . . . . . 12
4. Adjacency Maintenance . . . . . . . . . . . . . . . . . . . . 12
4.1. Adjacency Maintenance by IS-T . . . . . . . . . . . . . . 12
4.2. Adjacency Maintenance by IS-R . . . . . . . . . . . . . . 13
4.3. Use of BFD . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Graceful Restart Support . . . . . . . . . . . . . . . . 14
5. Operation of the Update Process on a UDL . . . . . . . . . . 14
Ginsberg, et al. Expires December 30, 2014 [Page 2]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
6. Support for UDL on the Return Path . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informational References . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Operation of IS-IS depends upon two-way connectivity. Adjacencies
are formed by exchanging hellos on a link, flooding of the link state
database is made reliable by exchanges between neighbors on a link,
etc. However, there are deployments where operation of the protocol
is desired over links which are unidirectional i.e., one end of the
link can only send Protocol Data Units (PDUs) and one end of the link
can only receive PDUs. Traditional methods of supporting
Unidirectional Links (UDLs) have involved establishing a tunnel from
the Intermediate System (IS) at the receive end of the UDL to the IS
at the transmit end of the UDL, encapsulating/decapsulating the IS-IS
PDUs as they enter/exit the tunnel, and associating the PDUs received
via the tunnel with the UDL at the transmit end. This typically
requires static configuration and may introduce Maximum Transmission
Unit (MTU) issues due to the required encapsulation.
This specification defines extensions to the protocol which support
correct and reliable operation of IS-IS over UDLs without the need
for tunnels or any form of encapsulation.
2. Encoding Extensions
Although the IS at the transmit end of a UDL link (IS-T) can send IS-
IS PDUs normally on the link, the IS at the receive end of a UDL link
(IS-R) requires assistance from other ISs in the network to pass the
information it would normally send directly to IS-T. The Update
Process as defined in [IS-IS] allows information generated by one IS
in the network to be reliably flooded to all other ISs in the network
using Link State PDUs (LSPs). The extensions defined here utilize
LSPs to allow IS-R to send information normally sent in hellos (IIHs)
or sequence number PDUs (SNPs) to IS-T in LSPs. As LSPs are flooded
to all ISs in an area/sub-domain, care is taken to minimize the LSP
churn necessary to support adjacency establishment and maintenance
between IS-T and IS-R.
Ginsberg, et al. Expires December 30, 2014 [Page 3]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
2.1. UDL LSPs and the UDL-TLV
Routers on the receive end of a UDL MUST reserve at least one LSP
(for each level supported on the UDL) to advertise the UDL
information described below. Such LSPs are referred to as UDL-LSPs
although the only distinction between a UDL-LSP and other LSPs is in
the TLV information which is present in such an LSP. LSP #0 MUST NOT
be used to send UDL information. UDL-LSPs have the following special
characteristics:
1. The only TLV which may be advertised in UDL-LSPs is the UDL TLV
described below and (optionally) an Authentication TLV and/or
Purge Originator Identification TLV [RFC6232] . This requirement
is enforced by the originator of the UDL-LSP but is not checked
by receiving systems i.e., other TLVs which are included in a
UDL-LSP are processed normally. The reason for the restriction
is to minimize the number of LSPs which have UDL information
content.
2. Routers on the transmit side of a UDL flood UDL-LSPs regardless
of the existence of an adjacency in the UP state on that circuit.
Flooding of UDL-LSPs on circuits other than a UDL is as specified
in [IS-IS] i.e., no special handling.
A new TLV is defined in which UDL specific information appears. All
information in a UDL-TLV is encoded in sub-TLVs. UDL sub-TLVs are
formatted as specified in [RFC5305]. The format of the UDL-TLV is
therefore:
No. of octets
+---------------------------+
| Type (11) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | 1
+---------------------------+
| Sub-TLVs | 3 - 255
: :
+---------------------------+
2.2. UDL Intermediate System Neighbors sub-TLV
UDL links may operate in Point-to-Point mode or in broadcast mode
(assuming the subnetwork is a broadcast subnetwork). There are
therefore two types of Intermediate System Neighbors sub-TLVs
defined. A UDL-TLV MUST NOT contain more than one Intermediate
Ginsberg, et al. Expires December 30, 2014 [Page 4]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
System Neighbors sub-TLV. If multiple Intermediate System Neighbors
sub-TLVs appear in a UDL-TLV all information in that UDL-TLV MUST be
ignored.
2.2.1. UDL Point-to-Point Intermediate System Neighbor Sub-TLV
The UDL Point-to-Point Intermediate System Neighbor Sub-TLV describes
an adjacency on a UDL which is operating in Point-to-Point mode i.e.
either a Point-to-Point subnetwork or a LAN subnetwork operating in
Point-to-Point mode as described in [RFC5309]. The information
encoded follows the format for the Point-to-Point Three-Way Adjacency
TLV as defined in [RFC5303] but may also include the local LAN
address when the underlying subnetwork is a LAN.
No. of octets
+---------------------------+
| Type (240) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length (9 + ID Length) | 1
| to (15 + ID Length) |
+---------------------------+
| Adjacency 3-way state | 1
+---------------------------+
| Extended Local Circuit ID | 4
+---------------------------+
| Neighbor System ID | ID Length
+---------------------------+
| Neighbor Extended Local | 4
| Circuit ID |
+---------------------------+
| Local LAN Address | 6
+---------------------------+
2.2.2. UDL LAN Intermediate System Neighbor Sub-TLV
The UDL LAN Intermediate System Neighbor sub-TLV describes an
adjacency on a UDL operating in broadcast mode on a LAN subnetwork.
Ginsberg, et al. Expires December 30, 2014 [Page 5]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
No. of octets
+---------------------------+
| Type (6) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length (7 + ID Length) | 1
+---------------------------+
| Neighbor LAN ID | ID Length + 1
+---------------------------+
| Local LAN Address | 6
+---------------------------+
2.2.3. Sub-TLVs Associated w an IS Neighbor
A number of sub-TLVs require the presence of a UDL IS-Neighbor sub-
TLV (either Point-to-Point or LAN) in the UDL-TLV in order to provide
appropiate context for the information being advertised. These sub-
TLVs are described in the sub-sections below.
2.2.3.1. UDL LSP Range sub-TLV
The content of this sub-TLV describes a range of LSPs for which the
originating router requires an update. Only the neighbor specified
in the associated UDL IS-Neighbor sub-TLV processes the LSP range
mentioned in this sub-TLV.
No. of octets
+---------------------------+
| Type (8) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length (ID Length + 2)* 2 | 1
+---------------------------+
| Start LSP ID | ID Length + 2
+---------------------------+
| End LSP ID | ID Length + 2
+---------------------------+
2.2.3.2. UDL LSP Entry sub-TLV
The content of this sub-TLV describes LSPs for which the originating
router requires an update. Only the neighbor specified in the
associated UDL IS-Neighbor sub-TLV processes the LSP entries
specified in this sub-TLV.
Ginsberg, et al. Expires December 30, 2014 [Page 6]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
No. of octets
+---------------------------+
| Type (9) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length (10 + ID Length)*N | 1
+---------------------------+
: LSP Entries :
+---------------------------+
Each LSP Entry has the following format:
+---------------------------+
| Remaining Lifetime | 2
+---------------------------+
| LSP ID | ID Length + 2
+---------------------------+
| LSP Sequence Number | 4
+---------------------------+
| Checksum | 2
+---------------------------+
2.2.3.3. Protocols Supported sub-TLV
This sub-TLV specifies the set of Network Layer Protocol Identifiers
(NLPIDs) that the originating system is capable of forwarding as
defined in [RFC1195].
No. of octets
+---------------------------+
| Type (129) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | Number of NLPIDs
+---------------------------+
: NLPIDs : 1 octet/NLPID
+---------------------------+
2.2.3.4. IP Address sub-TLV
This sub-TLV specifies the set of IP addresses configured on the
interface as defined in [RFC1195].
Ginsberg, et al. Expires December 30, 2014 [Page 7]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
No. of octets
+---------------------------+
| Type (132) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | 4 * # of addresses
+---------------------------+
: IP Address(es) : 4 octets/address
+---------------------------+
2.2.3.5. Multi-Topology sub-TLV
This sub-TLV specifies the set of topology identifiers supported as
defined in [RFC5120].
No. of octets
+---------------------------+
| Type (229) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | 2 * # of MTIDs
+---------------------------+
: MTIDs : 2 octets/MTID
+---------------------------+
NOTE: All flag bits defined in [RFC5120] MUST be transmitted as 0
and ignored on receipt.
2.2.3.6. IPv6 Interface Address sub-TLV
This sub-TLV specifies the set of IPv6 addresses assigned on the
local interface as defined in [RFC5308]. Addresses MUST be link
local addresses.
No. of octets
+---------------------------+
| Type (232) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | 16 * # of IPv6 addresses
+---------------------------+
: IPv6 Addresses : 16 octets/Address
+---------------------------+
Ginsberg, et al. Expires December 30, 2014 [Page 8]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
2.2.3.7. IPv6 Global Interface Address sub-TLV
This sub-TLV specifies the set of global IPv6 addresses assigned on
the local interface as defined in [RFC6119]. . Addresses MUST be
global or unique local addresses.
No. of octets
+---------------------------+
| Type (233) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | 16 * # of IPv6 addresses
+---------------------------+
: IPv6 Addresses : 16 octets/Address
+---------------------------+
2.3. UDL Manual Area Addresses sub-TLV
This sub-TLV specifies the set of manualAreaAddresses of the
originating system. No other sub-TLVs are allowed in a UDL-TLV which
has this sub-TLV. Any other sub-TLVs in such a UDL-TLV are ignored
on receipt.
No. of octets
+---------------------------+
| Type (1) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | 1
+---------------------------+
: Area Address(es) :
+---------------------------+
Each Area Address has the following format:
+---------------------------+
| Address Length | 1
+---------------------------+
| Area Address | Address Length
+---------------------------+
Ginsberg, et al. Expires December 30, 2014 [Page 9]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
3. Adjacency Establishment
An adjacency over a UDL link may be established over a link operating
in Point-to-Point mode (including a LAN subnetwork configured to
operate in Point-to-Point mode) or a link operating in broadcast
mode. Operation in either mode is identical except for some
differences in the manner of adjacency establishment as specified in
the following sub-sections.
IS-T utilizes the set of manualAreaAddresses advertised by IS-R in a
UDL Manual Area Address sub-TLV in combination with the UDL
Intermediate System Neighbor sub-TLV(s) to IS-T advertised by IS-R to
determine the level(s) associated with any adjacency to IS-R.
3.1. Adjacency Establishment in Point-to-Point Mode
Adjacency establishment makes use of Three Way Handshake as defined
in [RFC5303] when operating in Point-to-Point mode. When operating
over a LAN subnetwork, the use of point-to-point operation over LAN
as defined in [RFC5309] is also used.
IS-T initiates adjacency establishment by sending Point-to-Point IIHs
over the UDL as normal i.e., including Three-Way Handshake TLV. Note
that the local circuit ID specified by IS-T need only be unique among
the set of Point-to-Point UDL links supported by IS-T on which IS-T
is at the transmit end.
Upon receipt of a Point-to-Point IIH IS-R creates an adjacency in the
INIT state with IS-T and advertises the existence of the adjacency in
its UDL-LSP(s) utilizing the UDL Point-to-Point Intermediate System
Neighbor sub-TLV. The Local LAN address is included if the link is a
LAN subnetwork operating in Point-to-Point mode. UDL-LSPs of the
appropriate level(s) are generated according to the type of the
adjacency with IS-T.
When IS-T receives the UDL-LSP(s) generated by IS-R containing the
UDL Point-to-Point Intermediate System Neighbor sub-TLV it validates
the 3 way information and, if valid, transitions its adjacency to UP
state. In subsequent Point-to-Point IIHs IS-T includes IS-R's
circuit ID information as indicated in the UDL Point-to-Point IS
Neighbor sub-TLV in its 3 way handshake TLV. A complete set of CSNPs
is sent to IS-R for the level(s) appropriate for the type of
adjacency. LSPs which are updated as a result of the existence of
the adjacency to IS-R are sent to IS-R, but IS-T does NOT propagate
its full LSP Database. This is done to minimize the amount of
redundant flooding.
Ginsberg, et al. Expires December 30, 2014 [Page 10]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
IS-R uses normal adjacency bring up rules based on the 3 way
handshake information it receives in Point-to-Point IIHs from IS-T
and advertises its IS neighbor to IS-T in the usual manner i.e. in an
LSP other than a UDL-LSP. Following transition of the adjacency to
IS-T to the UP state IS-R MAY request IS-T to flood its complete LSP
Database by sending an LSP Range sub-TLV to IS-T in a UDL-LSP.
3.2. Adjacency Establishment in Broadcast Mode
IS-T initiates adjacency establishment by sending LAN IIHs of the
appropriate level(s) over the UDL as normal. IS-T specifies itself
in the LAN ID field of the IIH, including a non-zero circuit ID.
Note that the local circuit ID specified by IS-T need only be unique
among the set of LAN UDL links supported by IS-T on which IS-T is at
the transmit end. This is because pseudo-node LSPs will never be
generated for a UDL. Operation in broadcast mode supports a UDL with
a single IS-T and multiple IS-Rs.
Upon receipt of a LAN IIH PDU IS-R creates an adjacency in the INIT
state with IS-T and advertises the existence of the adjacency in its
UDL-LSP(s) utilizing the UDL LAN Intermediate System Neighbor sub-
TLV. UDL-LSPs of the appropriate level(s) are generated according to
the levels supported by IS-R and IS-T.
When IS-T receives the UDL-LSP(s) generated by IS-R containing the
UDL LAN Intermediate System Neighbor sub-TLV(s) it validates the
LANID and, if valid, transitions its adjacency to UP state. In
subsequent LAN IIH PDUs, IS-T includes IS-R's LAN Address as
indicated in the UDL LAN IS Neighbor info. A complete set of CSNPs
for the appropriate level is sent over the circuit. LSPs which are
updated as a result of the existence of the adjacency to IS-R are
sent to IS-R, but IS-T does NOT propagate its full LSP Database.
This is done to minimize the amount of redundant flooding.
IS-R uses normal adjacency bring up rules based on the IS Neighbor
LAN Address information it receives in LAN IIH PDUs from IS-T and
advertises its IS neighbor to IS-T in an LSP other than a UDL-LSP.
Note that there is no pseudo-node on a UDL LAN circuit - therefore
both IS-T and IS-R MUST advertise an IS Neighbor TLV to each other,
not to a pseudo-node. This is identical to what is done on a Point-
to-Point subnetwork. Following transition of the adjacency to IS-T
to the UP state IS-R MAY request IS-T to flood its complete LSP
Database by sending an LSP Range sub-TLV to IS-T in a UDL-LSP.
Ginsberg, et al. Expires December 30, 2014 [Page 11]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
3.3. UDL link metric configuration
What metrics are configured on a UDL depend upon the intended use of
the UDL. If the UDL is to be used for unicast forwarding, then IS-T
should be configured with the value appropriate to its intended
preference in the network topology and IS-R should be configured with
maximum link metric (2^24 -1) as defined in [RFC5305] (assuming wide
metrics are in use). If the UDL is to be used for building a
multicast Reverse Path Forwarding tree, then IS-R should be
configured with the value appropriate to its intended preference in
the network topology and IS-T should be configured with maximum link
metric (2^24 -1).If the link is to be used for both unicast
forwarding and multicast, then it is necessary to have two different
metric configurations and perform two different SPF calculations.
This may be achieved through the use of multi-topology extensions as
defined in [RFC5120]. Note that the configured link metrics have no
bearing on adjacency establishment - they only affect the building of
a Shortest Path Tree (SPT).
4. Adjacency Maintenance
This section defines how adjacencies are maintained once established.
Adjacency maintenance is defined without the need to send periodic
UDL-LSP updates as this would be a significant burden on the entire
network.
4.1. Adjacency Maintenance by IS-T
IS-T sends IIH PDUs as normal on a UDL. As IS-R does NOT send IIH
PDUs to IS-T, IS-T maintains the adjacency to IS-R so long as all of
the following conditions are TRUE:
o IS-T has a valid UDL-LSP from IS-R which includes Point-to-Point
UDL IS Neighbor information or LAN UDL IS Neighbor information (as
appropriate) regarding the adjacency IS-R has with IS-T on the
UDL.
o IS-T can calculate a return path rooted at IS-R to IS-T which does
not traverse the UDL on which the adjacency is associated
When either of the above conditions becomes FALSE, IS-T brings down
its adjacency to IS-R. Note that the return path calculation is only
required when a topology change occurs in the network. It therefore
need only be done in conjunction with a normal event driven SPF
calculation.
NOTE: Immediately after the adjacency to IS-R has come up, if the
only available return path traverses a UDL link on which the
Ginsberg, et al. Expires December 30, 2014 [Page 12]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
adjacency is still in the process of coming UP, the return path check
will fail. This is possible because we bypass normal flooding rules
to allow the UDL-LSP to be flooded even when the adjacency is not UP
on a UDL link (as described later in this document). If IS-T
immediately brings the adjacency to IS-R down in this case, a
circular dependency condition arises. To avoid this, if the return
path check fails immediately after the adjacency comes up, a timer Tp
is started. The timer is cancelled when a return path check
succeeds. If the timer expires, IS-T brings down the adjacency to
IS-R. A recommended value for the timer Tp is a small multiple
(e.g., "twice") of the estimated time necessary to propagate LSPs
across the entire domain.
Although it is unorthodox to bring up an adjacency without confirmed
two way connectivity, the extension is well grounded because the
receipt of IS-R's UDL-LSP by IS-T is indicative of the existence of a
return path even though it cannot yet be confirmed by examination of
the LSP database. This unconfirmed two way connectivity is a
condition which we do not want to persist indefinitely - hence the
use of timer Tp.
4.2. Adjacency Maintenance by IS-R
IS-R maintains its adjacency with IS-T based on receipt of IIHs from
IS-T as normal. So long as IS-T follows the rules for adjacency
maintenance described in the previous section this is sufficient.
Further protection against pathological behavior on the part of IS-T
(e.g., failure to perform the return path calculation after a
topology change) MAY be implemented by IS-R. When IS-R receives a
CSNP from IS-T which contains an SNP entry identifying an LSP which
is not in IS-R's Link State Database (LSDB) a timer Tf is started for
each such LSP. This includes entries which are older than, newer
than, or non-existent in IS-R's LSDB.The timer Tf is cancelled if:
o The associated LSP is received by IS-R on any circuit by normal
operation of the Update process or
o A subsequent set of CSNPs received from IS-T does not include the
LSP entry
If any timer Tf expires IS-R brings down the adjacency with IS-T.
In the absence of pathological behavior by IS-T the Tf extension is
not required. Its use is therefore optional.
Ginsberg, et al. Expires December 30, 2014 [Page 13]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
4.3. Use of BFD
A multi-hop BFD session [RFC5883] MAY be established between IS-T and
IS-R. This can be used to provide fast failure detection. If used,
this would also make the calculation by IS-T of a return path from
IS-R to IS-T optional.
Support for [RFC6213] requires that the BFD session come up before
the IS-IS adjacency comes up when both neighbors advertise BFD
support. In the event that there is a UDL link on the return path
from IS-R to IS-T and the adjacency on that link is also in the
process of coming up this could introduce a circular dependency
between the state of the BFD sessions and the state of the UDL
adjacencies. Therefore [RFC6213] is NOT supported on UDLs.
4.4. Graceful Restart Support
Graceful restart as defined in [RFC5306] is NOT supported on UDLs.
In the event IS-R is restarting, signaling of restart state would
require IS-R to regenerate UDL-LSPs prior to synchronization of the
LSPDB. In the event IS-T is restarting, LSPDB synchronization would
require the sending of CSNPs from IS-R to IS-T - which is not
supported.
5. Operation of the Update Process on a UDL
For purposes of LSP propagation IS-T views the UDL as if it were a
broadcast subnetwork where IS-T is the Designated Intermediate System
(DIS). This is true regardless of the mode of operation of the
circuit (point-to-point or broadcast). Therefore, IS-T propagates
new LSPs on the UDL as they arrive but after sending an LSP on the
UDL the SRM flag for that LSP is cleared i.e. no acknowledgement for
the LSP is required or expected. IS-T also sends periodic CSNPs on
the UDL.
IS-R cannot propagate LSPs to IS-T on the UDL. IS-R also cannot
acknowledge LSPs received from IS-T on the UDL. In this respect IS-R
operates on the UDL in a manner identical to a non-DIS on a broadcast
circuit. If an LSP entry in a CSNP received from IS-T identifies an
LSP which is "newer than" an LSP in IS-R's LSDB, IS-R MAY request the
LSP from IS-T by sending a UDL-LSP with an LSP entry as described
above. Since IS-R's UDL-LSP(s) will be propagated throughout the
network even though the information is only of use to IS-Ts, it is
recommended that some small delay occur between the receipt of a CSNP
from IS-T and the generation of a UDL-LSP with an updated LSP entry
by IS-R so as to allow for the possible receipt of the LSP either
from IS-T or on another link.
Ginsberg, et al. Expires December 30, 2014 [Page 14]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
If the number of LSP entries to be requested exceeds the space
available in the UDL TLV associated with the adjacency to IS-T, IS-R
MUST NOT generate multiple UDL TLVs associated with the same
adjacency. Instead it should maintain the state of SSN flags
appropriately for the LSP entries that require updates and send
additional LSP entries (if necessary) in a subsequent UDL-LSP after
the previously requested updates arrive.
Use of the LSP Range sub-TLV by IS-R allows more efficient encoding
of a request for multiple LSPs. This could be especially useful
following an adjacency UP event on a UDL. As described in Section 3,
IS-T does NOT propagate its full LSP database following transition of
an adjacency to IS-R to the UP state. This is consistent with IS-T
operating in the role of DIS on a broadcast circuit. If IS-R has
neighbors on other circuits it is possible that it will have received
LSPs from other neighbors. In such a case flooding of the full LSP
database by IS-T would be redundant. It is therefore left to the
discretion of IS-R to request those portions of the LSP database
which are not current. This is consistent with IS-R operating as a
non-DIS on a broadcast circuit.
On receipt of a UDL-LSP generated by IS-R, IS-T checks the neighbor
information in each UDL-TLV. If the information matches an existing
adjacency that IS-T has with IS-R then IS-T sets SRM flag on the UDL
for any LSPs in its LSDB which are "newer" than the corresponding
entries IS-R sent in LSP Entry sub-TLVs in UDL TLVs. SRM flags are
also set on the UDL for LSPs which fall in the ranges specified in
LSP Range sub-TLVs in UDL TLVs. UDL-TLVs associated with adjacencies
to routers other than IS-T are ignored by IS-T.
6. Support for UDL on the Return Path
If all return paths from IS-R to IS-T traverse a UDL, then in order
to bring up the adjacency between IS-T and IS-R at least one of the
adjacencies on a return path UDL must already be UP. This is
required because IS-T relies on receiving the UDL-LSP(s) generated by
IS-R in order to bring up its adjacency. In order to overcome a
circular dependency in the case where multiple pairs of UDL neighbors
are trying to bring up an adjacency at the same time, an extension to
LSP propagation rules is required.
When a new UDL-LSP is received by any IS which has one or more active
UDLs on which it is operating as an IS-T, the set of neighbors other
than the local system which are advertised in UDL-TLVs in the
received UDL-LSP is extracted - call this UDL-LSP-ISN-SET. A return
path from the originating IS-R to each neighbor in the UDL-LSP-ISN-
SET is calculated. If there is no return path to one or more
neighbors in this set periodic propagation of that UDL-LSP on all
Ginsberg, et al. Expires December 30, 2014 [Page 15]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
UDLs on which the local system acts as IS-T is initiated regardless
of the state of an adjacency on that UDL. Periodic transmission of
that UDL-LSP continues until a return path to all neighbors in the
UDL-LSP-ISN-SET exists. This calculation is redone whenever the UDL-
LSP is updated and when a topology change in the network occurs as a
result of updates to the LSDB. Note that periodic retransmission is
only done on UDLs on which the local system acts as IS-T.
If the network is partitioned the lack of a return path from a given
IS-R to a given IS-T may persist. It is therefore recommended that
the periodic retransmission employ an exponential backoff timer such
that when the partition persists the periodic retransmission period
is long enough so as to not represent a significant burden. It is
recommended that the periodic retransmission be initially set to the
locally configured CSNP interval. Note that periodic retransmission
is only performed on UDL links and if an IS-R has previously received
the same UDL-LSP it will silently ignore the retransmission since the
UDL-LSP will already be in its LSDB. Unnecessary reflooding of the
retransmitted UDL-LSP beyond the UDL does not occur.
IS-R MUST accept and propagate UDL-LSPs received on a UDL even when
there is no adjacency in the UP state on the UDL circuit. Flooding
of UDL-LSPs by IS-R uses normal flooding rules. LSPs received by
IS-R on the UDL which do NOT include UDL TLVs are discarded unless
the adjacency is UP (normal processing).
This extension allows establishment of an adjacency on a UDL even
when the return path transits another UDL which is also in the
process of bringing up an adjacency. The periodic nature of the
flooding is meant to compensate for the unreliability of the
flooding. After the adjacency is UP, IS-R can request LSPs from IS-T
by putting LSP entries into UDL-LSPs - but that ability is not
available until the adjacency is UP.
7. IANA Considerations
This document requires the definition of a new IS-IS TLV to be
reflected in the "IS-IS TLV Codepoints" registry:
Type Description IIH LSP SNP Purge
---- ------------ --- --- --- -----
11 Unidirectional Link Information N Y N Y
This document requires that a new IANA registry be created to control
the assignment of sub-TLV code points to be advertised within a
Unidirectional Link Information TLV. The registration procedure is
"Expert Review" as defined in [RFC5226]. The following sub-TLVs are
Ginsberg, et al. Expires December 30, 2014 [Page 16]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
defined by this document. Values are suggested values subject to
assignment by IANA.
Value Description
----- ------------------------------
1 Manual Area Addresses
6 LAN IS Neighbor
8 LSP Range
9 LSP Entry
129 Protocols Supported
132 IP Interface Address
229 Multi-topology
232 IPv6 Interface Address
233 IPv6 Global Interface Address
240 Point-to-Point IS Neighbor
8. Security Considerations
Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and
[RFC5310].
9. Acknowledgements
The idea of supporting IS-IS on UDLs without using tunnels or
encapsulation was originally introduced in the US patent "Support of
unidirectional link in IS-IS without IP encapsulation and in presence
of unidirectional return path" (patent number: 7,957,380), by Sina
Mirtorabi, Abhay Kumar Roy, Lester Ginsberg.
10. References
10.1. Normative References
[IS-IS] "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473), ISO/IEC
10589:2002, Second Edition.", Nov 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Ginsberg, et al. Expires December 30, 2014 [Page 17]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way
Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
October 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
2008.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, February 2011.
10.2. Informational References
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
RFC 5306, October 2008.
[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN
in Link State Routing Protocols", RFC 5309, October 2008.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC
6213, April 2011.
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
Originator Identification TLV for IS-IS", RFC 6232, May
2011.
Ginsberg, et al. Expires December 30, 2014 [Page 18]
Internet-Draft draft-ietf-isis-udl-02.txt June 2014
Authors' Addresses
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
USA
Email: ginsberg@cisco.com
Sina Mirtorabi
Cisco Systems
3800 Zankar Road
San Jose, CA 95134
USA
Email: smirtora@cisco.com
Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome 0144
Italy
Email: sprevidi@cisco.com
Abhay Roy
Cisco Systems
560 McCarthy Blvd.
Milpitas, CA 95135
USA
Email: akr@cisco.com
Ginsberg, et al. Expires December 30, 2014 [Page 19]
