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) > <[email protected]> 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 >> <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
