É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. ### Section 2 Please add a reference to LISP RFC(s). 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. ### Section 3 What is a `PETR`? ### 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 ;-) ### Section 4 Suggest adding the nodes X & Y already in figure 1. ### Section 5 Where are the S-bit and L-bit defined ? Probably in RFC 8060, but let's be 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. ### Section 7 I am afraid that [I-D.filyurin-lisp-elp-probing] is a normative reference. ### Section 8 s/One example is to implement a *honey-pot* service/One example is to implement a *packet scrubber* service/ ? _______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
