Thanks Erik, John, Dino. We’ll leave it as is then. Thanks! Alberto
From: Erik Kline <ek.i...@gmail.com> Date: Monday, February 13, 2023 at 3:32 AM To: John Scudder <j...@juniper.net> Cc: Dino Farinacci <farina...@gmail.com>, Alberto Rodriguez-Natal (natal) <na...@cisco.com>, The IESG <i...@ietf.org>, draft-ietf-lisp-pub...@ietf.org <draft-ietf-lisp-pub...@ietf.org>, lisp-cha...@ietf.org <lisp-cha...@ietf.org>, lisp@ietf.org <lisp@ietf.org> Subject: Re: [lisp] Erik Kline's No Objection on draft-ietf-lisp-pubsub-11: (with COMMENT) 👍 On Sun, 12 Feb 2023, 17:56 John Scudder, <j...@juniper.net<mailto: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<mailto: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<mailto:ek.i...@gmail.com>> wrote: >> >> >> On Sun, Feb 12, 2023 at 2:46 PM Dino Farinacci >> <farina...@gmail.com<mailto: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
