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 <[email protected]> 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 <[email protected]> wrote: >> >> >> On Sun, Feb 12, 2023 at 2:46 PM Dino Farinacci <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lisp
