Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)

[Dino Farinacci <[e-mail]>]

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.

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

> > 
> > > S 5.
> > >>       \ |           UDP Length          |        UDP Checksum           |
> > >>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >>         |                                                               |
> > >>         |                         LISP Message                          |
> > >>         |                                                               |
> > >>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > > What do these two diagrams correspond to? v4 and v6? This needs
> > > explanation.
> > 
> > It is th entire IP packet sent as a LISP control-message. The header before the diagrams indicate they are UDP packets.
> > 
> > A caption would probably help.
> 
> The beginning of the section shows an IPv4 UDP packet format as well as a IPv6 UDP packet format.
> 
> Agreed. I'm just saying you should put in a caption on each of them.

Done.

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

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

Dino