Mike Bishop has entered the following ballot position for draft-ietf-lisp-rfc6831bis-07: 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-rfc6831bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # IESG review of draft-ietf-lisp-rfc6831bis-07 CC @MikeBishop ## Discuss ### Section 4, paragraph 7 ``` PIM Join/ Prune message contains enough information to help the ITR build ingress-replicated unicast trees. ``` The "enough information" this message is specified in RFC 8059, but isn't referenced here. Even where it is, it's only an Informative reference, not Normative. Can this draft can be successfully implemented without consulting RFC 8059? ### Section 13 I am surprised, to put it mildly, that the new support for unicast underlays doesn't bring with it any new Security Considerations. This text appears largely unchanged from RFC 6831. The new unicast mode makes the ITR's replication list programmable by a remote party via RFC 8059's Receiver ETR RLOC Attribute. Yet RFC 8059 says "Security of Join/Prune attributes is only guaranteed by the security of the PIM packet. The attributes specified herein do not enhance or diminish the privacy or authenticity of a Join/Prune message." That sounds suspiciously like a traffic-redirection/amplification vector. Has this been analyzed anywhere? If there's an existing mitigation (deployment assumed fully trusted/single-operator, some out-of-band ACL, rate limiting at the ITR) it should be stated. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### RFC 6832: Normative vs. Informative? Comes up in several places within Section 9. Seems less critical to me than RFC 8059, but still worth a check. #### Section 9, paragraph 1 ``` This section describes the multicast corollary to [RFC6832] regarding the interworking of multicast routing among LISP and non-LISP sites. ``` Is the multicast restatement of this problem in this document complete enough to be read and implemented *without* consulting RFC6832? #### Section 9.1.1, paragraph 1 ``` propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP Network Address Translation (LISP-NAT) in [RFC6832] solves. ``` Are you sure that an understanding of LISP-NAT isn't required to implement this section? #### Section 9.1.1, paragraph 5 I'm unclear how an ITR decides when it should route via an mPETR. Is this clearly stated somewhere in this document or does it depend on RFC6832? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### "Abstract", paragraph 1 ``` - obsoletes RFC6831 + obsoletes RFC 6831. + + + ``` #### Section 1, paragraph 4 ``` - in other sites that are LISP enabled. - ^ + in other sites that are LISP-enabled. + ^ ``` #### Section 1, paragraph 13 ``` - even when the site is LISP enabled. That is, internal operation of - ^ - multicast is unchanged, regardless of whether or not the site is LISP + even when the site is LISP-enabled. That is, internal operation of + ^ + multicast is unchanged, regardless of whether or not the site is LISP- + + ``` #### Section 1, paragraph 13 ``` - LISP enabled. - ^ + LISP-enabled. + ^ ``` #### Section 3, paragraph 10 ``` +SP site (uLISP Site) that is also multicast-capable according to the procedur + ^ ``` #### Section 4, paragraph 14 ``` - where fan-out occurs to multiple sites, a underlay router will + where fan-out occurs to multiple sites, an underlay router will + + ``` #### Section 4, paragraph 18 ``` - (S-RLOC,G) joins and populates the OIF-list state for for the - ---- ``` #### Section 7.1, paragraph 2 ``` - [I-D.ietf-pim-jp-extensions-lisp] + [I-D.ietf-pim-jp-extensions-lisp]. + + ``` #### Section 9.1, paragraph 1 ``` - LISP enabled. So, most of the implications are in the underlay with - ^ + LISP-enabled. So, most of the implications are in the underlay with + ^ ``` #### Section 9.1, paragraph 6 ``` - are LISP-Multicast enabled; that has been discussed in previous - ^ + are LISP-Multicast-enabled; that has been discussed in previous + ^ ``` #### Section 9.1.1, paragraph 1 ``` - In the first scenario, a site is LISP enabled for both unicast and - ^ + In the first scenario, a site is LISP-enabled for both unicast and + ^ ``` #### Section 9.1.1, paragraph 4 ``` - site is LISP enabled or not. When it is not LISP enabled, the ITR - ^ ^ + site is LISP-enabled or not. When it is not LISP-enabled, the ITR + ^ ^ ``` #### Section 9.1.4, paragraph 1 ``` - receiver site can determine if a source multicast site is LISP + receiver site can determine if a source multicast site is LISP- + + ``` #### Section 9.1.4, paragraph 1 ``` - multicast site is a uLISP site, it is LISP enabled, but the ITR, by - ^ + multicast site is a uLISP site, it is LISP-enabled, but the ITR, by + ^ ``` #### Section 9.1.4, paragraph 3 ``` - sites; since they think the source multicast site is LISP enabled, - ^ - the ETR cannot know if the ITR is LISP-Multicast enabled. To solve - ^ + sites; since they think the source multicast site is LISP-enabled, + ^ + the ETR cannot know if the ITR is LISP-Multicast-enabled. To solve + ^ ``` #### Section 9.2, paragraph 16 ``` - either LISP-Multicast or uLISP enabled. This means that priority- - ^ + either LISP-Multicast- or uLISP-enabled. This means that priority- + + ^ ``` #### Section 9.2, paragraph 18 ``` - * When the source site is not LISP enabled, determining the address - ^ + * When the source site is not LISP-enabled, determining the address + ^ ``` #### Section 13, paragraph 3 ``` - Deployments have been succesfully able to leverage existing security - mechanisms deployed for PIM [RFC7761] + Deployments have been successfully able to leverage existing security + + + mechanisms deployed for PIM [RFC7761]. + + ``` #### Section 14, paragraph 1 ``` - No requests are made to IANA + No requests are made to IANA. + + ``` ### Section 3, paragraph 15 ``` infrastructure. It is likely a unicast PITR [RFC6832] hereafter referred to as uPITR in this document and an mPETR will be co- ``` This defines a new term inside the definition of a different term. Extract "uPITR" as its own term and definition. ### Section 7.1, paragraph 2 ``` These attributes are further enhanced in [I-D.ietf-pim-jp-extensions-lisp] ``` This is now RFC9798. ### Section 9.1.1, paragraph 6 ``` their way in the underlay to multicast PxTRs. Let's call this use of ``` Generally best to avoid first-person language in RFCs. ### Section 12, paragraph 2 ``` [MTRACE] [RFC8487]. ``` MTRACE appears to *be* RFC8487; why cite both? ### Grammar/style #### Section 3, paragraph 5 ``` ETR): as defined in [RFC9300]. Additionally it is a router that is on the pa ^^^^^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Additionally". #### Section 3, paragraph 7 ``` any-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 8, paragraph 3 ``` ticast site joins (S1-EID,Gi) through a underlay distribution tree of (RLOC1, ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 9.1.5, paragraph 1 ``` ves an (S-EID,G) join, it must select a S-RLOC for the same address family as ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". ## Notes This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
