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

[Eric Rescorla <[e-mail]>]

On Mon, Oct 8, 2018 at 5:41 PM Dino Farinacci <[e-mail]> 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
>
>
>