Hi Eric Thank you for your review and for sharing these constructive comments. Please see PPE below for our responses
On Thu, Jul 3, 2025 at 6:05 AM Éric Vyncke via Datatracker <[email protected]> wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-lisp-te-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-te/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-lisp-te-21 > CC @evyncke > > Thank you for the work put into this document. I am balloting NoObjection > *because* it is an experimental document, else I would ballot DISCUSS (see > points on section 5.4 and 7). > > Please find below some non-blocking COMMENT points/nits (replies would be > appreciated even if only for my own education). > > Special thanks to Padma Pillay-Esnault for the shepherd's detailed write-up > including the WG consensus and the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## COMMENTS (non-blocking) > > ### Shepherd's write-up > > I am a little puzzled to see the shepherd listed as authors as well; this is > quite unusual. I guess that the LISP chair/shepperd was added as an author late > in the process for the last mile of this document. > PPE> You are right. I was added as editor for the last mile of this document after the main author retired. This will be clarified in an updated shepherd write-up if needed. > > ### Section 2 > > Please add a reference to LISP RFC(s). > PPE> Agree will do. > More serious, I wonder whether the IETF needs to have yet another TE mechanism > (The ELP really looks like SRv6 or SR-MPLS SID list), but I guess that this can > be run as an experiment. > PPE> This draft has been around for a long time (started as a RG) and much of it predates more recent papers. At the time, the draft was a lower priority as the wg top priority was the LISP base specs, then later moving from experimental to standards track. We can add some text in the introduction that clearly frames this mechanism as one specific to the LISP architecture. > > ### Section 3 > > What is a `PETR`? PPE> “Proxy Egress Tunnel Router”. Several reviewers have pointed out as well a number of abbreviations and we will expand those on first use with a brief explanation, or a reference when needed or it will be added in the terms. >> > ### Use of SVG graphics > > To make a much nicer HTML rendering, suggest using the aasvg too to generate > SVG graphics. It is worth a try especially if the I-D uses the Kramdown file > format ;-) > PPE> Thanks for this suggestion, we will definitely give it a try. > > ### Section 4 > > Suggest adding the nodes X & Y already in figure 1. PPE> Agree that this will make it clearer > > > ### Section 5 > > Where are the S-bit and L-bit defined ? Probably in RFC 8060, but let's be > explicit. > PPE > You are correct, The S-bit and L-bit are defined in RFC 8060 will add text to make it explicit > > ### Section 5.4 > > Relying on the TTL only for loop avoidance is a severe limitation that would > not be acceptable in a proposed standard to be clear. A hostile participant > could then create a 255 tunnels loop if I understand correctly. PPE > Agreed. The TTL-based loop mitigation is used as a pragmatic safeguard, not a formal loop prevention mechanism. We will add text to clarify that proper encoding loop checks (e.g., ELP inspection) are expected for a standards track in the future. > > ### Section 7 > > I am afraid that [I-D.filyurin-lisp-elp-probing] is a normative reference. PPE> The draft is expired and we can put it in an Informative reference. We will add some text to describe ELP-Probing as an application of RLOC-Probing per RFC 9301 which should be in the normative reference. > > ### Section 8 > > s/One example is to implement a *honey-pot* service/One example is to implement > a *packet scrubber* service/ ? > > PPE> Agree will adopt your suggestion. Thanks for your insightful comments. The proposed changes will hopefully address your comments and will be reflected in the next iteration of the draft. Padma (and on behalf of the co-authors)
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
