draft-ietf-lisp-rfc6830bis-29.txt   draft-ietf-lisp-rfc6830bis-30.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Obsoletes: 6830 (if approved) V. Fuller Obsoletes: 6830 (if approved) V. Fuller
Intended status: Standards Track vaf.net Internet Consulting Intended status: Standards Track vaf.net Internet Consulting
Expires: July 11, 2020 D. Meyer Expires: July 16, 2020 D. Meyer
1-4-5.net 1-4-5.net
D. Lewis D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
January 8, 2020 January 13, 2020
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-29 draft-ietf-lisp-rfc6830bis-30
Abstract Abstract
This document describes the Data-Plane protocol for the Locator/ID This document describes the Data-Plane protocol for the Locator/ID
Separation Protocol (LISP). LISP defines two namespaces, End-point Separation Protocol (LISP). LISP defines two namespaces, End-point
Identifiers (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and Routing Locators
(RLOCs) that identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. With this, LISP
effectively separates control from data, and allows routers to create effectively separates control from data, and allows routers to create
overlay networks. LISP-capable routers exchange encapsulated packets overlay networks. LISP-capable routers exchange encapsulated packets
according to EID-to-RLOC mappings stored in a local Map-Cache. according to EID-to-RLOC mappings stored in a local Map-Cache.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 11, 2020. This Internet-Draft will expire on July 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 27, line 7 skipping to change at page 27, line 7
reachability problem, as traffic may be unidirectional. That is, the reachability problem, as traffic may be unidirectional. That is, the
ETR receiving traffic at a site MAY not be the same device as an ITR ETR receiving traffic at a site MAY not be the same device as an ITR
that transmits traffic from that site, or the site-to-site traffic is that transmits traffic from that site, or the site-to-site traffic is
unidirectional so there is no ITR returning traffic. unidirectional so there is no ITR returning traffic.
The echo-nonce algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if one side sets the
E-bit and the other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for echo-noncing, then the
echoing of the nonce does not occur and the requesting side may echoing of the nonce does not occur and the requesting side may
erroneously consider the Locator unreachable. An ITR SHOULD set the erroneously consider the Locator unreachable. An ITR SHOULD set the
E-bit in an encapsulated data packet when it knows the ETR is enabled E-bit in an encapsulated data packet when it knows the ETR is enabled
for echo-noncing. This is conveyed by the E-bit in the RLOC-probe for echo-noncing. This is conveyed by the E-bit in the Map-Reply
Map-Reply message. message.
Many implementations default to not advertising they are echo-nonce Many implementations default to not advertising they are echo-nonce
capable in Map-Reply messages and so RLOC-probing tends to be used capable in Map-Reply messages and so RLOC-probing tends to be used
for RLOC reachability. for RLOC reachability.
The echo-nonce mechanism SHOULD NOT be used over the public Internet The echo-nonce mechanism SHOULD NOT be used over the public Internet
and SHOULD only be used in trusted and closed deployments. Refer to and SHOULD only be used in trusted and closed deployments. Refer to
Section 16 for security issues regarding this mechanism. Section 16 for security issues regarding this mechanism.
11. EID Reachability within a LISP Site 11. EID Reachability within a LISP Site
 End of changes. 5 change blocks. 
6 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/