Ketan Talaulikar 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: ---------------------------------------------------------------------- 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. _______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
