Continuing my review:
Technical:
LISP Nonce: The LISP nonce field is a 24-bit value that is randomly
generated by an ITR when the N-bit is set to 1. The nonce is also
used when the E-bit is set to request the nonce value to be echoed
by the other side when packets are returned. When the E-bit is
clear but the N-bit is set, a remote ITR is either echoing a
previously requested echo-nonce or providing a random nonce. See
Section 6.3.1 <http://tools.ietf.org/html/draft-ietf-lisp-15#section-6.3.1>
for more details.
I read 6.3.1 and this text but it was still unclear to me if the nonces are
generated fresh on a per-packet basis, or if one nonce value is sent on a
stream of packets until you see it echoed back.
Can you clarify?
When doing ITR/PITR encapsulation:
o The outer header Time to Live field (or Hop Limit field, in case
of IPv6) SHOULD be copied from the inner header Time to Live
field.
Just checking: this happens *after* you have decremented the TTL/HL as you were
making a forwarding decision for the packet. So when the packet passes through
an ITR, the outer IP header has a TTL that is decremented by one compared to
the original packet, when looking at the packets on the wire. Right?
Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
after decapsulating, the net effect of this is that the new outer
header will carry the same Time to Live as the old outer header.
This seems wrong. Shouldn't the TTL be decremented even in this situation? But
I'm sure you thought about this. What am I missing?
The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
field and the IPv6 Traffic Class field [RFC3168
<http://tools.ietf.org/html/rfc3168>]. The ECN field
requires special treatment in order to avoid discarding indications
of congestion [RFC3168 <http://tools.ietf.org/html/rfc3168>]. ITR
encapsulation MUST copy the 2-bit ECN
field from the inner header to the outer header. Re-encapsulation
MUST copy the 2-bit ECN field from the stripped outer header to the
new outer header. If the ECN field contains a congestion indication
codepoint (the value is '11', the Congestion Experienced (CE)
codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
the stripped outer header to the surviving inner header that is used
to forward the packet beyond the ETR. These requirements preserve
Congestion Experienced (CE) indications when a packet that uses ECN
traverses a LISP tunnel and becomes marked with a CE indication due
to congestion between the tunnel endpoints.
This works for routers that do not participate in ECN process themselves. I suppose
it is theoretically possible that an xTR would also be doing ECN. Perhaps you could
add to the end of this paragraph: "In addition, at the end of the process
specified above, an ECN-capable xTR may perform its own modification of the ECN bits
per [RFC3168], when it detects congestion.
An ITR that is configured with mapping database information (i.e. it
is also an ETR) may optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the map-cache, it may originate a "verifying
Map-Request", addressed to the map-requesting ITR. If the ETR has a
map-cache entry that matches the "piggybacked" EID and the RLOC is in
the locator-set for the entry, then it may send the "verifying Map-
Request" directly to the originating Map-Request source. If the RLOC
is not in the locator-set, then the ETR MUST send the "verifying Map-
Request" to the "piggybacked" EID. Doing this forces the "verifying
Map-Request" to go through the mapping database system to reach the
authoritative source of information about that EID, guarding against
RLOC-spoofing in in the "piggybacked" mapping data.
I want to understand this better and I guess reading to the end of the document will answer some of
my questions. But as a general rule, I think we should not trust other nodes in the network to
claim alternative addresses for themselves, unless we can somehow verify (via return routability or
via mapping data base) that they appear to really be at that address. So I am wondering if the
"may originate" should become "originates". But I'm reading on.
Weight: when priorities are the same for multiple RLOCs, the weight
indicates how to balance unicast traffic between them. Weight is
encoded as a relative weight of total unicast packets that match
the mapping entry. For example if there are 4 locators in a
locator set, where the weights assigned are 30, 20, 20, and 10,
the first locator will get 37.5% of the traffic, the 2nd and 3rd
locators will get 25% of traffic and the 4th locator will get
12.5% of the traffic. If all weights for a locator-set are equal,
receiver of the Map-Reply will decide how to load-split traffic.
I am surprised by the last sentence. Do you really mean that the receiver has
the power to distribute, e.g., all traffic to the first locator? Or that the
load-split will be equal among the locators? If you mean the former, how do I
signal that I desire an equal load split? Send 49-51?
Editorial:
UDP Length: The UDP length field is for an IPv4 encapsulated packet,
the inner header Total Length plus the UDP and LISP header lengths
are used. For an IPv6 encapsulated packet, the inner header
Payload Length plus the size of the IPv6 header (40 bytes) plus
the size of the UDP and LISP headers are used. The UDP header
length is 8 bytes.
I had trouble parsing this text. The first sentence seems to say that the is
only for IPv4, but I think you mean that the values are calculated in different
ways for IPv4 and IPv6.
Please clarify/reformulate.
The format of the
last 4 bytes of the LISP header would look like:
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... format of the last 8 bytes of the LISP header ....
M: When set, it indicates a Map-Reply Record segment is included in
the Map-Request.
Unlike other bits this one has no name. Or is it the "Map-Reply Record Bit"?
S: This is the SMR bit. SeeSection 6.6.2
<http://tools.ietf.org/html/draft-ietf-lisp-15#section-6.6.2> for details.
Please expand SMR, as this is the first time this abbreviation appears in the
document.
S: This is the SMR bit. SeeSection 6.6.2
<http://tools.ietf.org/html/draft-ietf-lisp-15#section-6.6.2> for details.
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is
sending a Map-Request in response to a received SMR-based Map-
Request.
The naming looks somewhat odd. Maybe SMR-request and SMR-response bits, or
Solicited Map Request bit and Solicited Map Request Response bit...
IRC: This 5-bit field is the ITR-RLOC Count which encodes the
additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-
Address) pair must always be encoded. Multiple ITR-RLOC Address
fields are used so a Map-Replier can select which destination
address to use for a Map-Reply. The IRC value ranges from 0 to
31, and for a value of 1, there are 2 ITR-RLOC addresses encoded
and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.
Perhaps you should explicitly say that value 0 means there are 1 ITR-RLOC
addresses.
(You say only that "At least one pair must always be encoded", but does that
mean that value 0 is disallowed or that it means 1 pair?)
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
