LISP Traffic Engineering
draft-ietf-lisp-te-25

# É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/ ?

Thanks for adding text to explain why publication is requested as EXP, and addressing my question about the ELP-probing mechanism.

I'd strongly encourage changing the opening sentence of section 2, to insert the word “Experimental” before extension.

Please consider the following:

- Please expand LISP in the abstract.
- Please also define all abbreviations on first use, I expect this will hardly increase the word count much and can save reader pain.

Thanks to the authors and the WG for their work on this document.

I support Gorry's DISCUSS related to ELP probing. It seems to me that ELP Probing (section 7) is an integral part of the LISP TE solution. Without this feature, I wondering how an operator could monitor/verify these LISP TE paths. And if my understanding is correct then, draft-filyurin-lisp-elp-probing that is listed as informative should become a normative reference.

Regarding the experimental status for this draft, I note that the shepherd's report indicates that implementations exist. That conveys implementation experience has already been achieved. I guess the reason why this is experimental is because it relies on LCAF (RFC8060) which is in experimental status. This is not an issue per se with this document, but that the WG perhaps needs to reprioritize its work in promoting experimental documents to PS before sending more experimental documents for publication to the IESG. AFAIK LCAF and Vendor specific LCAFs are widely implemented and deployed LISP features and quite foundational but remain as experimental - please correct if I've got it wrong. So, more of a feedback to the WG chairs/AD.

Regarding Section 8 Service Chaining, I support Med's DISCUSS point. The text says "ITR can encapsulate packets to the RTR which will decapsulate and deliver packets to a scrubber service device." - however, there is no protocol specification that indicates which packets the RTR should send to the scrubber service? Is the RTR itself running the scrubber service and "all" LISP packets sent to it are subject to the scrubber? More details and clarifications will help. I would expect that the ELPs need some indication of the RTR also doing extra service functions? 

Regarding Section 10 Multicast, I believe some references to LISP multicast documents are necessary. Perhaps RFC6831 can be referenced again here. I am not sure if any other is needed.

Hi Padma, all,

Thank you for your effort to address the comments raised in my previous ballot [1]. Given the intended Experimental Status, I think that the changes made since -21 [2] are great.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/lisp/v82np6l3OCGORIrLZO9s-g_Ywmw/

[2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-lisp-te-21&url2=draft-ietf-lisp-te-24&difftype=--html

Thank you to Peter Yee for the GENART review.  

Thank you for explaining the unique procedural path of this document (https://mailarchive.ietf.org/arch/msg/lisp/qQsEndHf0AZyMqJet8Em3NALwkc/).

I support Gorry's DISCUSS - I am also unsure why this is an Experimental doc, and not a BCP or Informational one.

nit:    MUST choose to drop the packet

why not simply: MUST drop the packet. The use of MUST and "choose" seem odd to me.