Thanks Acee, We’ll wait for the new version from Dino and build on top with clarifying text in this section.
Marc From: Acee Lindem <acee.i...@gmail.com> Date: Thursday, July 18, 2024 at 9:08 AM To: Marc Portoles Comeras (mportole) <mport...@cisco.com> Cc: Dino Farinacci <farina...@gmail.com>, draft-ietf-lisp-name-encod...@ietf.org <draft-ietf-lisp-name-encod...@ietf.org>, LISP mailing list list <lisp@ietf.org>, rtgwg-...@ietf.org <rtgwg-...@ietf.org>, Routing Directorate <rtg-...@ietf.org> Subject: Re: Routing Directorate Last Call Review for "LISP Distinguished Name Encoding" - draft-ietf-lisp-name-encoding-08 HI Marc, > On Jul 18, 2024, at 11:51 AM, Marc Portoles Comeras (mportole) > <mport...@cisco.com> wrote: > > Acee, > >>> 3. In section 9.2, The description of the onboarding process includes > >>> very specific details that aren't fully explained. Would it be > >>> possible to describe the use case at a higher level? > >> > >> This is some text from the cisco guys. I don't know how to change that. > >> They have the intellectual property on it. > > >That’s fine with me then. It was just unclear to me how a DN would provide > >stability to the reliable transport session - would this allow the session > >to be recovered using a different UDP for? > The use-case described came up when running LISP in environments with > endpoint mobility. > In those environments is not uncommon to have LISP xTRs that, at times, don’t > have any endpoint locally connected. When this happens, these xTRs tear down > the TCP connection (or don’t even start it) because they don’t have any EID > to register with the Mapping System. > As you mention, when endpoints join the xTR again, the whole cycle starts > again. New EIDs are available, first a new UDP registration is sent and then > the xTR and MS re-establish the TCP session. > To avoid this churn the DN registration comes very handy, because it creates > a permanent EID to register and avoids constantly bringing the TCP session up > and down. Even with my very high-level understanding of LISP, this makes sense to me. I'll leave it to you as to whether you add a clarifying statement regarding the permanent EID. Thanks, Acee > Thanks, > Marc > From: Dino Farinacci <farina...@gmail.com> > Date: Tuesday, July 16, 2024 at 1:18 PM > To: Acee Lindem <acee.i...@gmail.com> > Cc: draft-ietf-lisp-name-encod...@ietf.org > <draft-ietf-lisp-name-encod...@ietf.org>, LISP mailing list list > <lisp@ietf.org>, rtgwg-...@ietf.org <rtgwg-...@ietf.org>, Routing Directorate > <rtg-...@ietf.org>, Marc Portoles Comeras (mportole) <mport...@cisco.com>, > Dino Farinacci <farina...@gmail.com> > Subject: Re: Routing Directorate Last Call Review for "LISP Distinguished > Name Encoding" - draft-ietf-lisp-name-encoding-08 > > This exposes my only high-level knowledge of the protocol itself. Maybe add > > a reference to [RFC9301] here as well. > > I will add. > > >> > >>> 2. In section 5, the final sentence fragment didn't parse and it > >>> wasn't obvious to me how to edit it - "As well as identifying > >>> the router name...". > >> > >> Fixed. Thanks. > >> > >>> 3. In section 9.2, The description of the onboarding process includes > >>> very specific details that aren't fully explained. Would it be > >>> possible to describe the use case at a higher level? > >> > >> This is some text from the cisco guys. I don't know how to change that. > >> They have the intellectual property on it. > > > > That’s fine with me then. It was just unclear to me how a DN would provide > > stability to the reliable transport session - would this allow the session > > to be recovered using a different UDP for? > > I don't know. I have copied Marc Portoles explicitly so he can comment. > > Thanks, > Dino
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
