Re: [lisp] Erik Kline's No Objection on draft-ietf-lisp-pubsub-11: (with COMMENT)

[Dino Farinacci]

Okay I see the confusion and how this could be misleading. I’m not sure how to fix this editorially. The 2 fields are in a “Map-Reply Record” which was only in a Map-Register. If a Map-Request would want to supply mapping entry, it would include a Map-Reply Record. But before pubsub was spec’ed there would be no way to encode the 2 new fields because the I-bit was not specified.  Since the pubsub spec introduces the I-bit the 2 fields can be included and needed for the new protocol operation sped ‘ed in the pubsub draft.  A possible fix is to have pubsub refer to 9301, section 5.6 but would be misleading to convey a Map-Register message which is not the intent. So I conclude no change should be made.  Dino On Feb 12, 2023, at 4:59 PM, Erik Kline <ek.i...@gmail.com> wrote:  On Sun, Feb 12, 2023 at 2:46 PM Dino Farinacci <farina...@gmail.com> wrote: The Map-Request registry can point to both 9301 and the new LISP PubSub RFC. That works, yes. I was wondering about the fact that the message itself just grew an extra 2 fields. It shouldn’t have.  Which fields are you referring to? If you are referring to site-ID and xTR-ID, those are existing fields in the Map-Register message (and not the Mal-Request message).  I'm referring to the xTR-ID field and Site-ID field, both of which appear to be described as being "added to the Map-Request message defined in Section 5.2 of [RFC9301]", per Section 4 of the draft.

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp