š On Sun, 12 Feb 2023, 17:56 John Scudder, <j...@juniper.net> wrote:
> For whatever itās worth, during my own review I noticed the introduced > fields and came to the same conclusion Dino does here, that itās OK as > written. > > $0.02, > > āJohn > > > On Feb 12, 2023, at 8:46 PM, Dino Farinacci <farina...@gmail.com> wrote: > > > > ļ»æ > > > > 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
