LISP Site External
Connectivity
Cisco Systems
San Jose
CA
USA
prakjain@cisco.com
Cisco Systems
San Jose
CA
USA
vimoreno@cisco.com
Cisco Systems
San Jose
CA
USA
shooda@cisco.com
This draft defines how to register/retrieve pETR mapping information
in LISP when the destination is not registered/known to the local site
and its mapping system (e.g. the destination is an internet or external
site destination).
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.
The LISP architecture and protocol [I-D.ietf-lisp-rfc6833bis]
introduces two types of replies to a map-request sent by an ITR:
- when the EID is known or registered to the mapping system, a
regular map-reply with mapping information is sent, or
- when the EID is unknown or known but not registered, a
negative-map-reply (NMR) is sent.
Currently the NMR does not convey pETR RLOC-set information to
specify where the ITR should send the packet.
This document describes how to use the LISP messages to register and
provide pETR RLOC-set information for destinations which are EIDs not
registered with the Mapping System, or simply are "not known" to be an
existing EID. These destinations could be the destinations which are
outside of the LISP site belonging to non-LISP domains, hence are not
registered with the LISP Mapping System.
The reachability of these destinations can be provided either by
configuring pETR information directly into the Mapping System, or by the
registration done by certain pETRs. The pETR registration is
specifically useful when the traffic to these external destinations
needs to be sent encapsulated to a preferred pETR/gateway chosen
dynamically. This mechanism also helps to achieve faster
convergence.
This document also specifies the structure of the map-reply
containing pETR RLOC-set information.
Same as defined in [I-D.ietf-lisp-rfc6833bis].
pETRs having external or internet connectivity MAY register the pETR
with the mapping system. The pETR Map-Register/Map-Notify procedures and
record format are the same as in [I-D.ietf-lisp-rfc6833bis] with the
following contents:
- An “EID-Prefix” as an agreed upon or configurable
"Distinguished Name" according to
[I-D.farinacci-lisp-name-encoding].
- RLOC-set for pETR information.
- Each locator in the RLOC-set MAY be encoded as per
[I-D.ietf-lisp-vpn]. This enables dynamic external connectivity in VPN
environments.
- Additional information MAY be encoded in vendor specific LCAF type
[I-D.ietf-lisp-vendor-lcaf] about the registering pETR such as its
performance matrix, resource availability for the Mapping System to make
preference decision.
The Map-Request procedures and record format are the same as in
[I-D.ietf-lisp-rfc6833bis].
When the Map-Server (or ETR) determines that the requested
destination is external or unknown to the mapping system, it sends a
Map-Reply containing the pETR information. The Map-Reply procedures and
record format are the same as described in the Map-Server processing
section of [I-D.ietf-lisp-rfc6833bis]. This Map-Reply has the following
content (as defined per regular map-reply and negative-map-reply in
[I-D.ietf-lisp-rfc6833bis]):
- An EID-Prefix calculated as non-LISP “hole” per the
procedures in [I-D.ietf-lisp-rfc6833bis] for negative map-reply.
- RLOC count MUST be non-zero.
- Each locator in the RLOC-set MAY be encoded as per
[I-D.ietf-lisp-vpn]. This enables dynamic external connectivity in VPN
environments.
- TTL MAY be shorter than regular map-reply.
- Additional information MAY be encoded in vendor specific LCAF type
[I-D.ietf-lisp-vendor-lcaf] about the mapping such as whether the
mapping is based upon policy or registration.
No IANA considerations apply to this document.
There are no additional security considerations except what already
discussed in [I-D.ietf-lisp-rfc6833bis].
The authors would like to thank Fabio Maino for the suggestions and
review of this document.