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

lisp-bounces@ietf.org 写于 2012-07-27 06:23:54:

>     > From: Michael Hoefling <hoefling@informatik.uni-tuebingen.de>
> 
>     > 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...)

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

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. 

> 
>     > 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
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> 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.