Hi John,
> On 15 Jun 2022, at 15:56, John Scudder <[email protected]> wrote: > > >> The action you are suggesting at the end of your discuss needs a new >> message, which is not inline with the design decision taken for this draft. > > I guess I didn’t express myself clearly. For example, in the case of > disagreement on KDF ID, since the ITR is going to throw away the Map-Reply > anyway, it appears as though the Map-Server could return a Map-Reply > containing LISP-SEC ECM Authentication Data whose EID-AD Length is 4 and > simply proposing a new KDF ID. That would reuse existing messages without > doing throwaway work, wouldn’t it? > Yes, but … There are two scenarios to consider: 1. The Map-Server is acting as proxy for the requested mapping. 2. The Map-Server does not act as proxy for the requested server. Case 1. If the Map-Server is acting as proxy, then it is entitled to reply with a Map-Reply on behalf of the ETRs registering the mapping. In this case it could (as you suggests) send back a Map-Reply proposing a different KDF ID, this is already in the specs. The next question IMO is what do you put in the reply itself? According to specifications if the mapping exists you send it back. In LISP there is no message “please ask again”. This is the part that generates overhead. Case 2. This is similar, just that now is the ETR that is replying. Same question as in previous case, what to put in the reply? Beside, the ETR is not aware that the Map-Server changed the KDF-ID, because there is no trace in the packet. Your suggestion is basically to send back something else. The LISP-SEC-ECM is a wrapper, it has to encapsulate a LISP Control Message, so you in order to work you need to define a new message or just put the Map-Reply. The current draft uses the second option. I am not arguing which solution is better, I am just trying to clarify the design choice that has been made by the authors and the WG. (As an input for your telecast tomorrow) Ciao L. > Thanks, > > —John _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
