Mohamed Boucadair has entered the following ballot position for draft-ietf-lisp-te-21: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Dino, Michael, Parantap, and Padma, Thank you for the effort put into this specification. Thanks to Dhruv Dhody for the OPSDIR review. Unless I’m mistaken, there was no discussion on these issues. Given the intended status, I won’t review the detailed procedure proposed here but will focus on the expected features. # Is this document ready for IESG Review? I failed to find follow-ups or updates to the IETF LC comments (directorate reviews are also part of the IETF LC comments). I won’t reiterate here the comments made by Dhruv and which I think are worth to consider. # Justification/Expectations for the intended Experimental status Please add similar text as what was agreed for the LISP Geo spec where we raised this same issue. Thanks. # Deployment Incentives Although this is experimental, a discussion on deployment incentives for this flavor of LISP TE (which is distinct from the one discussed, e.g., in RFC7834) is needed. Forcing some via-points (for some specific reasons) would require that domains that are not host LISP-capable routers to be upgraded to enable LISP for the sake of the service offered in this draft? What are the incentives for such domain to do so? I’m not mentioning issues related to adding an extra intermediate on the path with all the risk of interception, etc. Section 4 lists some reasons to enable the proposed features, but no justification/discussion is actually provided. Please see below some comments about that part. ## Lack of control of underlying path CURRENT: * There may be a policy reason to avoid the ASes that make up the path between B and C. xTR does not have control of the underlying path. Assuming that an internal path is made available to endpoints, avoiding some portion of a forwarding path may not be possible unless we assume that for every AS in the forwarding path a LISP RTR is enabled. That assumption is against the promise of initial LISP design. ## LISP specific for internal path failures is not a viable approach CURRENT: * There may be a failure on the path between B and C which makes the path unreliable. As failures are unpredictable, this assumes that the intended features to be efficient for this intended case must be enabled not only to react to the B-C leg failure but other similar failures of the path. That’s not a viable approach. Also, other traffic that LISP-encapsulated one will be impacted. A more generic protection mechanism to detect/absorb the failure is more appropriate than LISP-specific. ## Why another mechanism for service chaining is needed? CURRENT: * There may be a chain of services performed at RTRs X and Y regardless if the path from ITR to ETR is through B and C. There are few service chaining approaches already standardized by the IETF. A discussion why these mechanisms are not sufficient here is needed. Cheers, Med _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
