Dino, Thanks for your responses - mine are in-line below.
Alia On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci <[email protected]> wrote: >> 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. I agree that there's been lots of discussion on the list. Capturing the decisions made into the draft would be good practice, IMHO, and ensure it has been resolved. Can an ETR have an prefix which has a hole in it? What happens if the ETR does not know the correct RLOCs to use for that hole (since it isn't owned)? I'm thinking of a case where initially there is a LISP site with a /16. Then, part of that company is sold along with the /24 that is used in that division. Now, can the original site advertise the /16 with a hole? How would it do that? The problem here is that the ETR does NOT KNOW the correct locator-set for the /24 hole that has been sold off. >> 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 was looking for details beyond the basic packet manipulation. I gave a couple examples of the type of info I'm looking for in i) and ii) below. Having clearly specified behavior in one location that relates to packet-handling and errors/ICMP is useful. Another example is the R-bits manipulation... This is, I think, another place where there aren't experimental questions - and a very clear straightforward section describing what MUST be done would help with interoperability. >> 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. Another option is for the ETR to look up the EID in the mapping database and forward it. Or the ETR could try and route it assuming the destination IP address is globally routable. That the correct decision is to drop the packet is NOT specified. There are indications in the draft of decapsulation and reencapsulation & when those should be done is not specified. >> 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. Of course, I read through that section. My concern is the case where an ITR may set the DF bit to 0. "When the outer header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. 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." IF everything needs to be implemented, then an ETR has to be prepared for an ITR to do that (adversarially if nothing else) and handle reassembly at line-rate. >> 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. Do you think those are strong concerns inside a single LISP site? Rate-limited is not the same as completely removed. As specified, there is no mechanism for the end-host to tell what's happening to its packets. If you are going for parallelism to what an IP router does, then I think an ICMP Destination Unreachable is appropriate. IF not, then similarly specifying that it should not be sent & why would be useful. >> 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. An IP router doesn't have to figure out which end-host the message should have gone to instead; the ICMP packet would have gone there. This is a PURELY LISP problem. The ICMP packet is in response to an encapsulated packet. There are explicit mechanisms described to make sure that TTL exceeded works. What about Port Unknown or all the other ICMP messages that are intended to reach the end-host associated with the EID? How does an ITR know which EID was the source of the packet that the ICMP packet is responding to? >> 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. Is there a mechanism that is expected to inter-operate by which the cisco implementations do not need this? >> 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. OK - so the EID and RLOC space are *architecturally* different namespaces, but in reality any overlap is assumed to be used by the same entity and go to the same end-host?? >> 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. Yes - but while that eventually kills the packets, other traffic on the links is impacted and continues to be. If xTR A forwards a packet to ETR B who forwards it to ETR C and ETR C forwards it back to xTR A, there's a forwarding loop that continues to have a negative impact. TTL is to stop a packet caught in a forwarding loop from living forever in the network. It doesn't stop more packets from getting caught in the forwarding loop. >> 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. Then my comments will be 10 times as long... but I'll try. > 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. Yup - that sounds like future study to me. >> 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. Yes, there's a game in MPLS of deciding how many labels down one needs to go - but it has allowed a lot more flexibility. Anyhow, on the packet-handling bit - what should be done if this limit would be violated? >> 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". "but no explicit error-handling will be done??" >> 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. ;-) Sadly, I actually had. This is the TE-part, where an ITR needs to tell another ITR (I guess) or the end-host that the packet is too big. >> 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 Right - there is no description of DIFFERENT IP VERSIONS - e.g. IPv6 in IPv4 or IPv4 in IPv6 NOWHERE in the draft is this specifically said to be allowed or expected, but list conversations certainly imply it. >> 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. Yes, I was looking for something short, pithy, and sooner. This isn't a big deal - obviously, it is specified. I'd just missed it the first time or so reading through. >> 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. Yup - that is for the Map-Request and Map-Reply. It doesn't mean that it applies to the Echo-Nonce Locator Reachability Algorithm. In fact, I'd assumed that it didn't.. >> 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sorry, let me try again. The description and diagram for the L bit ignores the existence and changes done by the I bit. Is it possible to have the I and L bit both set? The description under the I bit implies that the L bit could be set to 1 - but gives the behavior if the L bit is 0. Just looking for consistency and clarity on this nit-picking detail. >> 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. What about a minor text change: "This bit indicates that the first 4 bytes of the LISP header is encoded as:" => "This bit indicates that the first 4 bytes of the LISP header is encoded as shown below in the complete LISP header." Again, this is more of a nitpick - but it was confusing the first couple times I read it over. >> 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. thanks >> 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. New text is clearer - or makes more sense to me now. >> 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. Really?? *shock* I wonder why - it seems quite dangerous to me. >> 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. Ah - the joys of defensive coding. Perhaps a hint that this isn't an expected condition and is an indication of an error (or at least a SHOULD violation). >> ", 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. So - I agree that the ITR should fragment first and then encapsulate - but the ITR MAY set the DF bit to 0. That's right above in the spec so I don't see how it is violating the spec - and it opens up the standard reassembly at line-rate problems to 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. That still sounds like future study to me - or at least a note that "work is on-going" or such. >> 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". Ok - I still think knowing about the packet types before they're talked about is useful - but the names are pretty descriptive in general. >> 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. It can be encapsulated!!! " UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is ITR/PITR selected and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. " > And each section indicates how each packet is sent. I was trying to combine the logic so it is clear what the set of common behavior is. >> 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. So - is this a reserved for future use thing? Where currently a Map-Request sender MUST set it to 0 and it MUST be ignored - for now? >> 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. K - clarification in the text? >> 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. It does?? Where was I supposed to have figured that out? I really did read all these drafts thoroughly! >> The Mapping Service is required for operation - so it should be ok for > > Not true. k - I was combining the mapping database and the mapping service interface. >> 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. I was trying to specify the use of the mapping system APIs and that logic. >> 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. But either the ITR is in charge of its cache or it isn't! If the ITR can't decide to remove the entry, then how can the ITR do cache management?? >> 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. That's going to make management fun - particularly of mixed environments. What about a recommendation for ICMP or at least consideration - so that it can be manageable when implemented by mere mortals? >> 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. Yes, the question isn't about the "within the highest priority" set. The question is why is there different logic specified in p.44 first bullet: " o Server-side sets weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs are unreachable. " versus the different and inconsistent on p.34 " 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. See Section 6.5 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values." I am asking why setting the weights for a locator-set equal (assume case with one priority for all) means that the ITR gets to decide how to split the traffic? If you want the ability to specify that, why not use a weight of 0 - as specified on p.44 and quoted in the first paragraph above. >> 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. K - did you add some text specifying this? Otherwise, I can see the set bouncing... >> 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. I meant 2nd paragraph as opposed to the bullets. It is below. " For security reasons an ITR MUST NOT process unsolicited Map-Replies. To avoid map-cache entry corruption by a third-party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR- based Map-Request and the source is not in the locator-set for the stored map-cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data." > 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. ?? K - where is that specified? I agree that it makes sense for system design - though it can cause problems in terms of latency. >> 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. Hmm, what about a brief intro comment such as: "As in the case of data-probes, ..." >> 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. Some specification of these cases as examples would bring clarity. And the death of one lemming doesn't stop the others from going over the cliff :-) >> 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. Oh - ok. I'm used to it being standard practice. How else would they be managed? Thanks - I don't think you missed a question! Alia >> Looking forward to your responses, >> Alia > > Thanks again, > Dino/Vince/Darrel/Dave > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
