On Mon, Oct 8, 2018 at 5:41 PM Dino Farinacci <[email protected]> wrote:
> Sorry the delay Eric. > > > > > > > S 5.5. > > > >> is being mapped from a multicast destination EID. > > > >> > > > >> 5.5. EID-to-RLOC UDP Map-Reply Message > > > >> > > > >> A Map-Reply returns an EID-Prefix with a prefix length that is > less > > > >> than or equal to the EID being requested. The EID being > requested is > > > > > > > > How do I behave if I receive an EID-Prefix that is less than any of > my > > > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > > > and someone asks me for 10.0.0.0/8? > > > > > > > > I think I'm still unclear on this point. > > > > The spec says you cache it. That is all you can do. But it means the > sender of the Map-Reply is not spec conformant. That means RLOCs are used > for the coarser EID-prefix. > > > > Sorry, cache it? My question is how to respond to the case where the > Map-Request has this property. > > I thought you were referring to the Map-Reply. If a Map-Request is sent > for 10.0.0.0/8 a replier needs to return in a Map-Reply /8, if it is > registered in the mapping system as well as all more specifics. That is > seldom done since a Map-Request is triggered for a destination EID in an IP > packet, but a “lig” client to ask to see if the coarser prefix exists. > OK. Thanks. > > > > > > > Also, when you talk about prefix > > > > length, I assume you mean the length fo the mask? > > > > > > Yes, this is explained later in this section. Was that not helpful?? > > > > > > I found it a bit confusing. It seems to me like there are two lengths > involved here: > > > > > > - The length of the field (4 or 16) > > > - The parts of the field that are significant (i.e., the mask) > > > > In routing, as you know, the mask-length is always the same as the > prefix-length. It is the number of bits in the mask. > > > > > > > I had thought that "prefix length" referred to the former, but it > seems like here it > > > refers to the latter. > > > > The length of the address is defined by the 16-bit AFI that precedes the > address. > > > > I agree, but the text refers to this as the prefix and it has a length, > which is the length of the encoded field, not the length of the mask, as > seen in this excerpt: > > > > EID-Prefix: This prefix is 4 octets for an IPv4 address family and > > 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 > > or 2, respectively. For other AFIs [AFI], the length varies and > > for the LCAF AFI the format is defined in [RFC8060]. When a Map- > > I will make this more clear. Thanks for the comment. Fixed in the section > you cite and make it more clear the different of “address length” and “mask > length” in the “EID-Prefix” definition. > Sounds good. > > > > S 5.3. > > > >> 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 the "piggybacked" mapping data. > > > > > > > > This text here doesn't seem compatible with either of the two cases > > > > listed in "EID-prefix" above. > > > > > > I don’t understand the comment Eric. Maybe because I can’t find the > exact reference to EID-prefix where you think there is a conflict. Please > cite for me. Thanks. > > > > > > This does seem to have been assigned to the wrong text. > > > > > > I am referring to: > > > > > > " A Map-Reply returns an EID-Prefix with a prefix length that is less > > > than or equal to the EID being requested. The EID being requested > is > > > either from the destination field of an IP header of a Data-Probe or > > > the EID record of a Map-Request. The RLOCs in the Map-Reply are > > > " > > > > > > versus > > > > > > " EID-Prefix: This prefix is 4 octets for an IPv4 address family and > > > 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 > > > or 2, respectively. For other AFIs [AFI], the length varies and > > > for the LCAF AFI the format is defined in [RFC8060]. When a Map- > > > " > > > > > > This is just the question of whether "prefix length" refers to the > field or > > > the significant bits of the field. > > > > Prefix-length = mask-length = number-of-bits-in-mask = value-after-/. > > > > OK, but then this second excerpt seems contradictory. We have an > EID-Prefix field which has a different length which is dictated by the AFI > only. > > It is not contracdictory. Let me explain, if I have a map-cache entry > 10.0.0.0/8 and I want to query the mapping system, then I send a > Map-Request for 10.0.0.0/8. What comes back in the Map-Reply is the /8 > and more specifics if they are registered. > > The definition section is saying what is in a Map-Request and the other > section that is describing behavior when a Map-Reply is returned. > OK. I'm going to assume that the changes you note above fixed my confusion here as well. > > > > S 8.3. > > > >> of the mapping database protocols. > > > >> > > > >> 8.3. Map-Server Processing > > > >> > > > >> Once a Map-Server has EID-Prefixes registered by its client > ETRs, it > > > >> can accept and process Map-Requests for them. > > > > > > > > This section is confusing because the introduction says that this > > > > function is only performed by Map-Resolvers: > > > > ' > > > > "The LISP Mapping Service defines two new types of LISP-speaking > > > > devices: the Map-Resolver, which accepts Map-Requests from an > > > > Ingress > > > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a > > > > mapping database; and the Map-Server, which learns authoritative > > > > EID- > > > > to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes > > > > them in a database.” > > > > > > The document does cover the operation of a Map-Resolver and a > Map-Server. Some functions are performed only by Map-Resolvers only and > other different functions are performed by Map-Servers only. > > > > > > I am not sure what you don’t understand. > > > > > > Sure: As I understand it, Map Resolvers process Map Requests, and Map > Servers do not (that's what the quoted text seems to say). However, this > sentence talks about a Map Server processing a Map Request. That's where I > am confused. > > > > Here is a brief scenario: > > > > (1) ITR sends Map-Request to a Map-Resolver. > > (2) Map-Resolver “finds” the Map-Server where the EID could be > registered. That is the mapping database transport system, two examples are > LISP-ALT and LISP-DDT. > > (3) The Map-Resolver in the case of LISP-DDT, will have a referral-cache > and know which map-server is authoriative for the EID-prefix the > Map-Request EID is for. > > (4) The Map-Resolver forwards the Map-Request to that Map-Server. > > > > And hence Map-Servers process Map-Requests. The Map-Server can > proxy-reply with the RLOC-set cached in its site-cache or forward to one or > more ETRs (described by the RLOC-set) so they can map-reply. > > > > Sure, this seems reasonable, but then perhaps the text above could be > revised, because it reads like Map Resolvers process these requests and > therefore implies that Map-Servers do not. > > In the intro we are trying to explain at high-level the service interface.. > But since Map-Resolvers forward Map-Requests to Map-Servers, they process > them to. But its through indirection. > OK, thanks. -Ekr Dino > > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
