Re: [lisp] draft-ietf-lisp-rfc6833bis-14 8.4.1 Anycast Map-Resolver Operation

Well I would say so much has changed since that paragraph was written where we have xTR-IDs  used for the association and registration between an ETR and a map-server and with newer ways of authentication (like using different keys per ETR with same anycast address as well as signature-IDs) we should lighten from SHOULD NOT to MAY. 

I’m willing to change it if there are no objections. 

Dino

> On Sep 16, 2018, at 3:05 PM, Darrel Lewis (darlewis) <darlewis=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> This turns out to be not the case Renne.  The idea of map-server resiliency is attractive.  But any-cast works best for non-stateful cases, and the relationship between an ETR and a MS is by definition, stateful.
> 
> -Darrel
> 
>> On Sep 16, 2018, at 3:17 AM, Rene 'Renne' Bartsch, B.Sc. Informatics <ietf=40bartschnet.de@dmarc.ietf.org> wrote:
>> 
>> Hi,
>> 
>> "draft-ietf-lisp-rfc6833bis-14" section "8.4.1 Anycast Map-Resolver Operation" says
>> 
>> "Note that Map-Server associations with ETRs SHOULD NOT use anycast
>> addresses, as registrations need to be established between an ETR and
>> a specific set of Map-Servers, each identified by a specific
>> registration association."
>> 
>> In my opinion it is sensible to use anycast addresses for map servers of a distributed database for fail-over/load balancing cases and the "SHOULD NOT" is to limiting.
>> 
>> Instead I suggest to encourage operators to specifially consider possible pitfalls of anycast operation.
>> 
>> 
>> Regards,
>> 
>> 
>> Renne
>> 
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp