I have reviewed this this draft and think it needs more work before it
is ready to proceed.
I have a few general questions and comments - as well as text-
specific ones.
Thanks for the thorough review Alia, it is appreciated. See responses
in line. Sorry it took over a month to get back to you on this.
I hope this leads to fruitful discussion on the list. I am also happy
to add all of these to
the Issue Tracker if necessary.
1) Can an EID and an RLOC have the same value? They are different
namespaces,
but assumptions in the various drafts imply not. Could this please
be explicitly stated?
See my explanation below.
2) Where is the explicit text saying what EID-prefixes an ETR can
register or reply authoritatively? E.g. Can an ETR advertise a prefix
(10.1/16) with holes (10.1.1/24)? Answer should be no, of course, but
extremely clear
rules on this are needed.
If the site has an EID-prefix of the /16 that is the one it Map-
Replies for. We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply
Message" on how to send Map-Replies when there are overlapping EID-
prefixes and there has been much discussion on this mailing list about
it.
3) Generally, a section specifying ETR behavior in regard to packets
is missing. What is specified is scattered widely.
"in regard to packets" is not clear what you are asking for. Do you
mean for decapsulation purposes? If so,
in section 5.3 starting with text "When doing ETR/PETR decapsulation:"
will explain it.
i) For instance, if an ETR receives a LISP encapsulated packet and
decapsulates it,
but does not have EID locally, what should the ETR do?
Drop the packet. When decapsulation occurs, the inner header is
inspected and what an IP router does today is what it does post
decapsulation.
ii) Does an ETR have to do packet fragment reassembly? If an ETR
does not support
fragment reassembly, should it send an ICMP Too Big message and
drop the fragment?
What should an ETR do with a fragment directed to its RLOC?
The ETR follows the IP and IPv6 specification in regards to reassemly
of fragments. However, we try to avoid fragmentation. See section 5.4
"Dealing with Large Encapsulated Packets" for solutions.
4) Generally, a section specifying ITR behavior in regard to packets
is missing.
i) For instance, if an ITR receives a Negative Map Reply indicated
"drop", should the ITR send an ICMP Destination Unreachable with
Host Unreachable?
We did not want to specify this because in practice when this is done
either the ICMP messages are either rate-limited or filtered so ICMP
is not a reliable mechanism.
Experimentation will tell us more on what to do.
ii) If an ITR receives an ICMP packet (other than TTL exceeded) to
its RLOC, how does it properly handle or forward it?
Just like an IP router does today.
5) Are interfaces inside the LISP site explicitly configured on the
xTR or is there a way for the ITR to identify them?
That is up to the implementation, but the 3 cisco implementations do
not have this explicit configuration.
Here are my questions tied specifically to the points in the text (and
some typos):
Consider these done. I will comment for which comments we will make a
change and when you don't see that, we did not make a change for your
comment.
a) On p 8 in EID-prefix:
"A globally routed address block may be used by its assignee as an
EID block."
There are comments in other drafts also being last-called that imply
it is possible to tell is a value is an EID or an RLOC - but other
places, such as this, where it is clear that a value may be both an
EID and an RLOC.
An address is an EID for sake of encapsulation when it is found in the
mapping database. Since EID namespace and RLOC namespace
*architecturally* are different spaces, an EID and an RLOC can have
the same value. In practice, we believe when a prefix is not in the
BGP DFZ core routing tables and registered to the mapping database is
when the personality of an IP address changes from an locator prefix
to an EID-prefix.
In practice, we have to deal with interworking, so we will find that
EID-prefixes will be in the DFZ for transition purposes. And an EID-
prefix and a regular route-prefix do not have to match, one can be a
more-specific of the other which does complicate things. In any event,
using more specific lookup matches, as we have been doing for decades
in the routing system, will continue to happen. So if a destination
address in a packet matches a more specific prefix in the mapping
database, then the destination is considered an EID. If the more
specific route is in the DFZ, then the destination is not considered
an EID and is routed natively.
I like to call the addresses we use today as locators or RLOCs. Not
everyone agrees with this thinking because things are more complicated
than that. But I would like to think the addresses that are in the DFZ
routing table today are "topological locations" and when a locator or
RLOC is used in LISP, it is exactly this same routable address that is
used.
Clarification of this is important
b) p. 10 Reencapsulating Tunnels: I do not see any references or
suggestions on how these would be used. I am also concerned about how
routing/forwarding loops are prevented.
The rules for TTL decrement occur across these re-encapsulating
boundaries.
Could this be explicitly set as for future study & experimentation?
The use-cases are cropping up and yes we are experimenting with
solutions for them.
I can see ways to make it work and ways that might fail - but nothing
providing details or mechanisms to avoid, detect, handle, or manage
problems.
c) p. 13: 3rd paragraph from bottom: The discussion about prepending
additional LISP headers for TE doesn't give any indications or ideas
of how an ISP transit might identify that it needs to prepend a TE-ETR
RLOC or how it would find such an RLOC. Given the complete lack of
detail about this in this draft and the others being last-called,
please explicitly specify this as experimental and for future study.
Please when you make comments, provide the text from the spec, so
others reading this can understand the context. So for others, here is
the paragraph that Alia is referring to:
An additional LISP header may be prepended to packets by a TE-ITR
when re-routing of the path for a packet is desired. An obvious
instance of this would be an ISP router that needs to perform
traffic
engineering for packets flowing through its network. In such a
situation, termed Recursive Tunneling, an ISP transit acts as an
additional ingress tunnel router and the RLOC it uses for the new
prepended header would be either a TE-ETR within the ISP (along
intra-ISP traffic engineered path) or a TE-ETR within another ISP
(an
inter-ISP traffic engineered path, where an agreement to build
such a
path exists).
It was mentioned at a working group meeting that a Traffic Engineering
draft needs to be written, but since that is out of charter, it has
not been assigned. Perhaps, when the working group changes charter
after posting of the experimental RFCs, we can do this work.
Also, please change "An obvious instance of this would be..." to "A
potential use-case would be..."
Consider this changed.
d) p. 13: 2nd paragraph from bottom: What is the appropriate behavior
for an ITR to do when it receives a packet that it would normally
prepend a LISP header to but cannot? Could you please add a "SHOULD
drop and SHOULD send back an ICMP message"? I don't see an
appropriate
code point defined yet...
Here is the 2nd paragraph from the bottom of page 13:
In order to avoid excessive packet overhead as well as possible
encapsulation loops, this document mandates that a maximum of two
LISP headers can be prepended to a packet. It is believed two
headers is sufficient, where the first prepended header is used at a
site for Location/Identity separation and second prepended header is
used inside a service provider for Traffic Engineering purposes.
To contradict the idea that 2 headers is sufficient, just look at the
deployment draft where a LISP site is dangling off another LISP site -
causing 2 LISP headers and then the possibility of a Service Provider
wanting to prepend one for TE purposes.
Right, when we go off and do the TE spec, we will decide if this
should be lifted. We want this to be strict now because hardware
engineers want a hard limit. My feedback from doing MPLS in hardware
was that having it variable length and limitless was a huge problem.
So most hardware implementations of MPLS ship with just 2 label stacks.
Third, please rephrase the "It is believed..." to something like "The
LISP experiment will presume..." or "LISP experimentation will start
with the assumption that..."
I changed the text to "For initial LISP deployments, is is assumed two
headers is sufficient".
e) Sec 5, first paragraph: How does an ITR that wants to encapsulate a
LISP-encapsulated packet for TE send back an ICMP Too Big message?
You didn't get to section 5.4 yet. When you get there, you should have
your answers. ;-)
f) Sec 5: There is no indication in the packet formats that IPv4 in
IPv6 or IPv6 in IPv4 SHOULD be supported. I don't care about long
format sections - but at a minimum, there should be a paragraph that
specifies the encapsulation possibilities:
"A LISP packet consists of an outer header, a UDP header, and an
inner header. The following combinations MUST be supported:
i) IPv4 outer header and IPv4 inner header (in Sec. 5.1)
ii) IPv6 outer header and IPv4 inner header
iii) IPv6 outer header and IPv6 inner header (in Sec 5.2)
iv) IPv4 outer header and IPv6 inner header "
I don't understand this comment. The summary is in the table of
contents section names:
5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . .
16
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . .
17
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . .
17
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . .
19
g) An explicit statement that a LISP data packet appears as a UDP
packet destined to port 4341 and a LISP control packet appears as a
UDP packet destined to port 4342 would help for those who skim packet
formats.
You can find that here in section 5.3:
UDP Header: The UDP header contains a ITR selected source port when
encapsulating a packet. See Section 6.5 for details on the hash
algorithm used to select a source port based on the 5-tuple of
the
inner header. The destination port MUST be set to the well-known
IANA assigned port value 4341.
and here for control packets:
The LISP UDP-based messages are the Map-Request and Map-Reply
messages. When a UDP Map-Request is sent, the UDP source port is
chosen by the sender and the destination UDP port number is set to
4342. When a UDP Map-Reply is sent, the source UDP port number is
set to 4342 and the destination UDP port number is copied from the
source port of either the Map-Request or the invoking data packet.
Implementations MUST be prepared to accept packets when either the
source port or destination UDP port is set to 4342 due to NATs
changing port number values.
h) p.19: When is it desirable to not have a Nonce value in a packet?
The Map-Version seems rather useful; which is required for support for
the initial LISP experimentation?
When doing the echo-nonce Locator Reachability Algorithm.
Also, the Nonce field could use similar description to that on p.29
for the Nonce value - at least as far as how to produce one and
what it is protecting against.
It says it here:
Nonce: An 8-byte random value created by the sender of the Map-
Request. This nonce will be returned in the Map-Reply. The
security of the LISP mapping protocol depends critically on the
strength of the nonce in the Map-Request message. The nonce
SHOULD be generated by a properly seeded pseudo-random (or strong
Farinacci, et al. Expires December 8, 2011 [Page 29]
Internet-Draft Locator/ID Separation Protocol (LISP) June 2011
random) source. See [RFC4086] for advice on generating security-
sensitive random data.
i) p. 20 L: The diagram indicates that the 2nd 32 bits are only
Locator Status Bits, but the description under the I bit indicates
that the I and L bit could be set at the same time - in which case the
2nd 32 bits aren't just Locator Status Bits. Please align the diagram
and description to better match the existence of the I bit.
I think you misread this. The text and the diagrams are consistent.
And you must note the binary settings (with the notation of "x" as
don't care bits). See here:
L: The L bit is the Locator-Status-Bits field enabled bit. When
this
bit is set to 1, the Locator-Status-Bits in the second 32-bits of
the LISP header are in use.
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
j) typo: p. 20 V
"This bit indicates that the first 4 bytes of the LISP header is
encoded as:"
but it show the 8 bytes of the LISP header and the second 4 are shown
as being "Instance ID/Locator Status Bits"
Right, the description wants to show the entire LISP header but wants
you, the reader, to focus on the ulong that the V-bit is pertaining to.
Also, for the I bit, the last 4 bytes are referred to, but all 8 are
shown.
Same as above comment.
k) p. 21 flags: I think this should be a "It MUST be set to 0 on
transmit and MUST be ignored on receipt" - if we want it to be really
available for the future...
Same for the Reserved field on p.29, p.33
Consider text updated for all 3 places.
l) typo p. 21, end of LISTP Locator Status Bits:
"with that address taht the ETR is considered 'up'" -> ITR
I think the ITR is the one who decides and sets the LSBs...
Fixed typo. No it is ETR.
m) p. 21/22: The TTL copying from inner to outer should be a MUST not
a SHOULD on encapsulation. The TTL copying from outer to inner should
be a MUST not a SHOULD on decapsulation.
It was agreed on by the working group to be SHOULD.
Why does the draft say "when the Time to Live field of the outer
header is less than the Time to Live of the inner header"? How could
that not be the case if copying the TTL from inner to outer is
required? Please remove the text:
Because there can be a bug on the ITR/PITR where it is violating the
spec.
", when the Time to Live field of the outer header is less than the
Time to Live of the inner header. Failing to perform this check can
cause the Time to Live of the inner header to increment across
encapsulation/decapsulation cycle. This check is also performed
when doing initial encapsulation when a packet comes to an ITR or
PITR destined for a LISP site."
n) Sec 5.4: This says that both, either or neither of the mechanisms
can be implemented. However, in Sec 5.4.1, it says:
"An implementation MAY set the DF bit in such headers to 0 if it has
good reason to believe there are unresolvable path MTU issues
between the sending ITR and the receiving ETR."
This transforms the requirement from being imposed just on the ITR to
something that the ETR has to deal with. If a LISP-encapsulated
packet is fragmented, then the ETR needs to do the reassembly.
Right, and the ITR has violated the spec. The spec is saying that
fragmentation is done first and encapsulation second so the end-system
reassembles and not the ETR.
o) Sec 5.5: While an Instance ID allows disambiguation of addresses, I
do not see any means of requesting or obtaining a EID-to-RLOC mapping.
There is no such field in the Map-Request or Map-Reply messages. It
doesn't work with [ALT]. Please add a paragraph such as:
"While a LISP header can contain an Instance ID, there are currently
no provisions for requesting or receiving an EID-to-RLOC mapping
that considers Instance-IDs. A LISP-NAT (described in [INTWRK]) may
provide a better solution for private addresses. The use of
Instance-ID as described here is provided for future study."
The AFI encoded addresses can carry different address formats. Once
AFI is called LCAF. See draft-farinacci-lisp-lcaf-05.txt for details.
p) Sec 6.1: "The following new UDP packet types are used to retrieve
EID-to-RLOC mappings"
Please change to the more accurate:
"The following new UDP packet formats are used for LISP control
packets. The different packet types are listed in Sec. 6.1.1."
I changed to the first sentence. Thanks.
Please move Sec 6.1.1 to before Sec 6.1 - so that readers know the
allocated packet types before reading the descriptive text.
This part introduces UDP. We go the the LISP header in the next sub-
section. That is why it was sequenced that way. Note in section 6
there is no details of the format of the "LISP Message".
After the packet formats, please change:
"The LISP UDP-based messages are the Map-Request and Map-Reply
messages. When a UDP Map-Request is sent, the UDP source port is
chosen by the sender and the destination UDP port number is set to
4342. When a UDP Map-Reply is sent, the source UDP port number is
set to 4342 and the destination UDP port number is copied from the
source port of either the Map-Request or the invoking data packet."
to
"When a Map-Request or a Map-Register, encapsulated or not, is sent,
the UDP source port is chosen by the sender and the destination UDP
port number is set to 4342. When a Map-Reply or Map-Notify is sent,
the source UDP port number is set to 4342 and the destination UDP
port number is copied from the source port of either the Map-Request
or the invoking data packet."
I prefer to not change it to what you suggest. Because you could imply
from your text that a Map-Register message is encapsulated.
And each section indicates how each packet is sent.
q) Sec 6.1.2: Is the A bit ever non-zero for a Map-Request?
We did not want to specify it but we were thinking of an option where
the Map-Request sender could request an authoritative request so if
there were cachers of a matching mapping, that the cachers would send
to the ETRs.
r) Sec 6.1.2: Why is the p bit needed? What does a ETR do based upon
the Map-Request coming from a PITR (or not)?
It is useful for debugging. The ETR could cache the number of PITRs
that have sent Map-Requests to it.
s) Sec 6.1.3 first paragraph: Without LISP encapsulation and a
Map Server, there isn't a way for an ITR to send a Map-Request to a
destination-EID.
If the ITR is connected to the ALT, it can send the Map-Request to a
destination EID. It assumes that the ALT carries EID-prefixes in its
routing system.
The Mapping Service is required for operation - so it should be ok for
Not true.
the draft to mention the interfaces to it! How about replacing this
first paragraph with the below:
"An ITR can need to send a Map-Request for numerous reasons (e.g. to
get a mapping for an EID, testing an RLOC for reachability, or
refreshing a mapping before TTL expiry). When the ITR knows an RLOC
for the relevant ETR (e.g. from the map-cache entry), the ITR can
create a Map-Request destined directly to that RLOC. If the ITR
does not know the relevant ETR to query, then the Mapping Service
[LISP-MS] must be used. To do this, the ITR creates a Map-Request
destined to the destination-EID and LISP encapsulates it as an
"Encapsulated Control Message" that is destined to the Mapping
Service [LISP-MS]. When an ITR receives a successful Map-Reply, the
ITR updates the cached set of RLOCs associated with the EID prefix
range."
We don't want to say this right here because there are too many
options and if we reduce the set, we don't want to rewrite this text.
The API to the mapping system that xTRs use are the Map-Request, Map-
Reply, and Map-Register messages. That we don't want to change if we
change the mapping system. Right now, the mapping system is pretty
modular and it is easy to change in and out without modifications to
ITRs and ETRs.
t) p.33 Record TTL:
"Record TTL: The time in minutes the recipient of the Map-Reply will
store the mapping. If the TTL is 0, the entry SHOULD be removed
from the cache immediately. If the value is 0xffffffff, the
recipient can decide locally how long to store the mapping."
Since the ITR controls its own cache and cache entries, what I think
you meant and would be more clear is:
"Record TTL: The maximum time in minutes that the recipient of the
Map-Reply may store the mapping. If the TTL is 0, the entry MUST
be removed from the cache immediately. IF the value is 0xFFFFFFFF,
the mapping does not expire and may be stored indefinitely."
You changed "will" to "may". We wanted stronger language than what you
provided. We don't want ITRs to ignore TTL values.
u) p. 33 No-Action: What packet encapsulation can happen!??!! There's
no RLOC to send the packet to! Please clarify.
I will fix and say, the packet is dropped. Thanks.
v) p. 33 Drop: On dropping the packet, is the sender ever notified?
What about some ICMP for troubleshooting?
Up to the implementation.
w) p. 34 Weight: Why is the ETR specifying that all locators get equal
weight used for the ITR getting to decide? This seems like a valid
decision by the ETR! Why not use weight=0 means ITR gets to decide as
clearly specified on p.44 first full bullet?
The ETR allows the ITR to decide *within the highest priority* set of
locators.
x) p. 36 Mapping Protocol Data: [ALT] does not use this field. Please
remove the reference.
Agree, will remove.
y) p.46: What happens when two ITRs send different LSB information
(e.g. in the case of a partitioned LISP site)?
The ETR can note the fact and decide to probe each one to find out
what is going on. If the LSBs are in conflict, the ETR can conclude
that the site is partitioned.
z) p.53 2nd paragraph from end: Unsolicited SMR-based Map-Requests
MUST be sent to the mapping database system seems like an easy way to
do a DDoS on the mapping database system - and have them all look
valid and authenticated.
That is not what the 2nd paragraph on page 53 says. Again, this is
confusing to parse since you don't sight the exact text.
Map-Requests of all kind need to be rate-limited if the implementation
is spec compliant. If not, then the MR should rate-limit accepting
them. We did not specify this since there are all sorts of ways to
mitigate this and more experimentation will be necessary to understand
solutions better.
aa) Sec 7: How is a tunnel encapsulated packet received by an ETR with
an EID in the destination? Do you mean a non-LISP-tunnel encapsulated
packet??
Years ago we used a concept of data-probes. That was a map-request in
the form of an encapsulated data packet where the inner destination
and outer destination were the same value. This assumed the core
carried EID-prefixes. This is still in the spec because there are
people who believe packets should not be dropped while waiting for a
Map-Reply to be returned to an ITR.
ab) Sec 8 last bullet:
"The technique of re-encapsulation ensures that packets only require
one tunnel header. So if a packet needs to be rerouted, it is first
decapsulated by the ETR and then re-encapsulated with a new tunnel
header using a new RLOC."
When would this legitimately happen? It seems like risking looping...
When you want to redirect your encapsulation to an intermediate point
for TE purposes, packet scrubbing purposes, to go through a stateful
firewall, etc. And the TTL copying rules make it not loop forever.
ac) Sec 14: The list of LISP Control Packet types (Sec 6.1.1) should
also be an IANA registry...
That has not been decided by the working group.
Looking forward to your responses,
Alia
Thanks again,
Dino/Vince/Darrel/Dave
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
