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 <[email protected]> Date: Thursday, July 18, 2024 at 9:08 AM To: Marc Portoles Comeras (mportole) <[email protected]> Cc: Dino Farinacci <[email protected]>, [email protected] <[email protected]>, LISP mailing list list <[email protected]>, [email protected] <[email protected]>, Routing Directorate <[email protected]> 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) > <[email protected]> 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 <[email protected]> > Date: Tuesday, July 16, 2024 at 1:18 PM > To: Acee Lindem <[email protected]> > Cc: [email protected] > <[email protected]>, LISP mailing list list > <[email protected]>, [email protected] <[email protected]>, Routing Directorate > <[email protected]>, Marc Portoles Comeras (mportole) <[email protected]>, > Dino Farinacci <[email protected]> > 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 -- [email protected] To unsubscribe send an email to [email protected]
