Subject: [lisp] Last call for draft-ietf-lisp-12

From: Terry Manderson <[email-masked]>
Date: Sun, 1 May 2011 17:09:18 -0700

All,

The authors of draft-ietf-lisp-12 have requested a work group last call.

Here starts the last call for this document, Joel and I will end the last
call on Monday the 16th May, 2011.

Please review the draft and provide any last comments.

Cheers
Terry

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 May 2011 18:12:37 -0400

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.

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?

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.

3) Generally, a section specifying ETR behavior in regard to packets
is missing.   What is specified is scattered widely.

   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?

   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?

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?
  ii) If an ITR receives an ICMP packet (other than TTL exceeded) to
  its RLOC, how does it properly handle or forward it?

5) Are interfaces inside the LISP site explicitly configured on the
xTR or is there a way for the ITR to identify them?

Here are my questions tied specifically to the points in the text (and
some typos):

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.

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.

Could this be explicitly set as for future study & experimentation?

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.

Also, please change "An obvious instance of this would be..." to "A
potential use-case would be..."

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...

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.

Third, please rephrase the "It is believed..." to something like "The
LISP experiment will presume..." or "LISP experimentation will start
with the assumption that..."

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?

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 "

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.

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?

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.

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.

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"

 Also, for the I bit, the last 4 bytes are referred to, but all 8 are
 shown.

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

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...

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.

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:

  ", 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.

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."

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."

Please move Sec 6.1.1 to before Sec 6.1 - so that readers know the
allocated packet types before reading the descriptive text.

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."

q) Sec 6.1.2:  Is the A bit ever non-zero for a Map-Request?

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)?

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.

The Mapping Service is required for operation - so it should be ok for
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."

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."

u) p. 33 No-Action: What packet encapsulation can happen!??!!  There's
no RLOC to send the packet to!  Please clarify.

v) p. 33 Drop: On dropping the packet, is the sender ever notified?
What about some ICMP for troubleshooting?

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?

x) p. 36 Mapping Protocol Data: [ALT] does not use this field.  Please
remove the reference.

y) p.46: What happens when two ITRs send different LSB information
(e.g. in the case of a partitioned LISP site)?

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.

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??

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...

ac) Sec 14: The list of LISP Control Packet types (Sec 6.1.1) should
also be an IANA registry...

Looking forward to your responses,
Alia

On Sun, May 1, 2011 at 8:09 PM, Terry Manderson
<[email-masked]> wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>