[lisp] Re: Routing Directorate Last Call Review for "LISP Distinguished Name Encoding" - draft-ietf-lisp-name-encoding-08

["Marc Portoles Comeras (mportole)" <[e-mail]>]

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