Subject: Re: [lisp] Fwd: Comments about draft-cheng-lisp-shdht-01

From: [email-masked] (Noel Chiappa)
Date: Fri, 27 Jul 2012 09:23:54 -0400 (EDT)

> From: Michael Hoefling <[email-masked]>

    > I assume that the proxy reply mode should not be the default operation
    > mode.
    > ... no P-bit not proxy.

That's my understanding - but sometimes I get a little confused on these fine
details! So if I have made a mistake, I trust someone will let us know! :-)

The whole question of having to get the mappings from the ETRs is one I have
thought about a fair amount, because it (currently) makes it impossible to
cache mappings in, e.g., the MR.

(Let me quickly clarify that "currently" - although I have thought about how
to cache mappings, I don't believe there are any plans to do so at the moment
- at least, not that I am aware of. It would require changing the Map-Reply
format, to indicate which ranges of 'source' EIDs a particular mapping is
valid for. So unless we have to change the Map-Reply format for some other
reason - e.g. to include signatures on mappings - my guess is that this is
unlikely to happen. And it's not clear if we need to cache mappings at
intermediate points between the authoritative source [the ETR] and the user
[the ITR] - although the DNS does have this capability, IIRC. Well, that's
the kind of thing we will discover through trying it...)

It is a slightly odd design choice in a way - it's a bit of an odd form for
the subsystem boundary (compared to other systems which provide mappings). It
wasn't until I started thinking of the ALT/etc as 'indexing systems' (which
is not how they were orginally described, I think) that it started to be
easier for me to think about. 

    >> This is necessary for things like 'source-specific mappings' (where an
    >> ETR returns different mappings to different ITRs).

    > Isn't this possible in proxy mode as well or is the selection logic
    > specific for ETRs?

Well, there is no way in the ETR/MS interface to specify that there are
multiple mappings, and which mappings should be given to which sources. So,
it is necessarily onl the ETRs which can provide source-specific mappings.

    > How is this currently achieved in DNS?

Do you mean 'how does DNS return different mappings to differerent lookup
requests' (as I gather a few people do, for load-balancing reasons, etc etc).
I don't know the details - I assume it's implementation-specific.

	Noel

---

From: [email-masked]
Date: Sun, 29 Jul 2012 21:15:40 -0700

> the kind of thing we will discover through trying it...)

Dissagree.

According to section 5.3 of "draft-ietf-lisp-sec":"The second bit after 
the Type field in a Map-Register message is allocated as the S bit. The S 
bit indicates to the Map-Server that the registering ETR is LISP-SEC 
enable."

And in section 5.7 of the same draft:"If the Map-Server is in proxy mode, 
it generates a Map-Reply, as specified in [I-D.ietf-lisp], with the S-bit 
set to 1. The Map-Reply includes the Authentication Data that contains the 
EID-AD, as well as the PKT-AD."

As a result, Map-Reply message need not to be changed. There's already 
mechanism for a Map-Server in proxy model to reply authenticate mapping 
information.

> it is necessarily onl the ETRs which can provide source-specific 
mappings.

According to discussion with Vincer:

"Why do ETRs have to send Map-Replies directly to ITRs?"

ETRs may have different policies for different ITRs, such like priority 
and weights of RLOCs. ETRs could send Map-Replies based on local policies.

IMO, ETRs could also register policies with mapping information, and 
require Map-Server to implement Policy decision.

In this scenario, complexity issue of mapping database need to be 
considered further. 

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.