Thanks, Mohamed, for your detailed review comments. Kindly find responses inline with GVP1> The changes accepted will be published as ver-11 Thanks Prasad
-----Original Message----- From: Mohamed Boucadair via Datatracker <[email protected]> Sent: Tuesday, September 15, 2026 07:55 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Mohamed Boucadair's Discuss on draft-ietf-lisp-rfc6831bis-07: (with DISCUSS and COMMENT) Mohamed Boucadair 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: ---------------------------------------------------------------------- Hi Dino, Dave, John, Stig, and Vengada, Thank you for the effort put into this specification. Please find below some points for discussion: # Multiple LISP Multicast Solutions: Need for clear applicability/positioning There are at least two approaches to provide multicast in LISP: 6831 and 8378 both were experimental. I see that the WG is also working on RFC8378bis. Each of those have deployment assumptions either on the underlying network or the Mapping System. It seems that both mechanisms were deployed (as gleaned in this document), which is great. However, I’m missing a discussion in both documents about the target applicability of each. Having a brief text (common to both -bis document) would help fix the this. Better, based on the experience gained with both mechanisms, it would be helpful to have some guidance when the optimization in 8378 would be sufficient (for cases with uLISP). GVP1> Thanks for the comment, this is very insightful. A few observations for your consideration: to my knowledge RFC6831 implementations are far ahead in implementation compared to RFC8378. Agreed both are in -bis stages now in the PS track, but the maturity of RFC6831 (deployment in particular) far exceeds RFC8378. Having said this, what you suggest is a very important aspect to be covered, my only request is we do it in a separate document rather than doing it in the respective -bis documents (6831-bis and 8378-bis). I hope this is reasonable to you. Kindly let me know # BCP 229 on Deprecating Any-Source Multicast (ASM) for Interdomain Multicast CURRENT: This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. .. PIM-ASM: The ASM mode of PIM [RFC7761], the most popular form of PIM, is deployed in the Internet today by having shared trees within a site and using source trees across sites. … Therefore, there are only operational (and not protocol) changes for PIM-ASM [RFC7761], Multicast Source Discovery Protocol (MSDP) [RFC3618], Anycast-RP [RFC4610], and PIM-SSM [RFC4607]. BIDIR-PIM [RFC5015], which typically does not run in an inter-domain environment, is not addressed in depth in this document. … When ASM and PIM-BIDIR are used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in an IPv6 group address [RFC3956]. There are several statements in the document about the inter-domain scope. However, it is not clear to me to what extent the use of ASM mode in the document adheres to BCP 229, which deprecates ASM for interdomain. Can we please clarify that? GVP1> Yes, added text to clarify that the RFC6831 adheres to BCP229 (RFC8815) but still provides the compatibility required if the deployment choses to use ASM. Please see text below ''' The specifications of this document are fully adherent to the recommendations outlined in <xref target="RFC8815/>. However, if a deployment choses to use PIM-ASM or inter-domain multicast, the specification of this document allows it. ''' # MSDP & IPv6 CURRENT: MSDP: MSDP [RFC3618] is used to announce active multicast sources to other routing domains (or LISP sites). However, RFC 8815 says: As a result of this key scalability and security issue, along with other deployment challenges with the protocol, MSDP was never extended to support IPv6 and remains an Experimental protocol. The document does not acknowledge these limitations, especially vs. IPv6. GVP1> Agreed, added the text below: ''' Since MSDP was never extended to IPv6 <xref target="RFC8815"/>, the scope of MSDP considerations outlined in this document are limited to IPv4 addresses only. ''' # EIDs and PI CURRENT: The terminology in this section is consistent with the definitions in [RFC9300] but is extended specifically to deal with the application of the terminology to multicast routing. ..but we do have statements such as: CURRENT: Endpoint ID (EID): As defined in [RFC9300], a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-Prefix block associated with the site in which the host is located. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC3376] or Multicast Listener Discovery Version 2 [RFC3810] [RFC4604]. LISP uses Provider-Independent (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. GVP1> Agreed, removed the last sentence of the above paragraph ## EID can be assigned following conventional techniques in stub networks. Why do we need to make the assumption on the nature of EIDs for LISP in general? ## What that MUST NOT buy us here? Isn’t that interfering with the definition of RLOC: CURRENT: Routing Locator (RLOC): as defined in [RFC9300] # MLD CURRENT: The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today -- they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs; that is, they join (S-EID,G). If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs. Not sure why only IGMP is called out here? I suggest to mention both IGMP and MLD. GVP1> Agreed. This has already been addressed in ver-08 # How the ETR knows the mode to use? CURRENT: 3. When using a multicast underlay, the ETR will build two PIM Join/Prune messages, one that contains an (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other that contains an (S-RLOC,G) entry so the underlay network can create multicast state from this ETR to the ITR. 4. When using a unicast underlay, the ETR will build one PIM Join/ Prune message, one that contains an (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects. This PIM Join/ Prune message contains enough information to help the ITR build ingress-replicated unicast trees. As the document is about operational changes, what are the required configuration actions at the ETR? is there a mode that is enabled by default? Please consider adding such details. GVP1> Agreed. Added the bullet preceding (3) above. <li><t>All LISP sites should be provisioned with the underlay they must use. Other methods of selecting the underlay are outside the scope of this specificaiton.</t></li> <li> # The current model assumes that the same address family is used at stub networks and core LISP. How about having an IPv6-only core and having xTRs to use IPv4-conventred IPv6 addresses for servicing IPv4 endpoints? See, for example, Section 7 of RFC8114. It is completely fine to declare this out of scope. GVP1> Sec 9.2 states "Multicast ITRs will only encapsulate packets where the inner and outer headers are from the same address family." Hence this will be defined out of scope for the current document. Added the following text: " Delivery of IPv4 multicast services to IPv4 clients over an IPv6-only core network <xref target="RFC8114"/> is outside the scope of this document." # Scalability CURRENT: This architecture is consistent and scalable with the architecture presented in [RFC9300] where multicast state in the underlay operates on Locators, and multicast state at the sites operates on EIDs. Some performance considerations need to be taken into account as several copies are replicated in the core. How to interpret “scalable” in this context? GVP1> My understanding is that scalable refers to the most minimal state required for replication in the core. Do you have any specific text in mind, kindly let me know. # Possible solution CURRENT: There is a possible solution to this problem that reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but "n" can reduce to a smaller number in the "n-to-1" relationship. And in turn, this reduces the opportunity for data packets to be delivered to sites for groups not joined ## Was this tried in the deployments stated in the document? GVP1> Yes, I am aware of one implementation (Cisco IOS-XE) where n overlay (source, groups) map to using a single RLOC address. ## to what extent there are deployments that rely on such multiple RLOC allocation scheme? GVP1> I guess this feature is important to save forwarding table (TCAM) space for the underlay multicast routing state. ## is this “possible solution” something that can be really recommended? GVP1> Yes # Consistency with RFC9300 CURRENT: Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast. rfc9300/#section-14 In the context of LISP, a multicast group address is both an EID and an RLOC. Instead of having text that may be interpreted as conflicting with RFC9300. I would suggest to leverage Section 14 of RFC9300. GVP1> Agreed, added reference to RFC9300 Sec 14. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Operational Considerations CURRENT: Therefore, there are only operational (and not protocol) changes for PIM-ASM [RFC7761], Multicast Source Discovery Protocol (MSDP) [RFC3618], Anycast-RP [RFC4610], and PIM-SSM [RFC4607]. BIDIR-PIM [RFC5015], which typically does not run in an inter-domain environment, is not addressed in depth in this document. The document is clear that the scope is on the operational changes. However, although the document includes a walk-though protocol operation, it does not include relevant configurations that are needed at various xTR elements. Please refer to draft-ietf-opsawg-rfc5706bis-07 - Guidelines for Considering Operations and Management in IETF Specifications for a guidance on considerations to take into account. GVP1> Added a new section 12 on Operational considerations based on the above draft recommendations. # Changes vs. 6831 Please include a description of the main changes vs. 6831. This can be added in an appendix. GVP1> This has been already addressed. Please check ver-10 # Successful deployment CURRENT: Deployments have successfuly demonstrated the successful minimization of multicast state in the underlay. The cost of this optimization is the extra amount of multicast packets that get sent in the same underlay tunnel. ## Not sure how that minimization was assessed and in which scale. ## Unless we have public pointers to cite here, I’m not sure having this text is helpful for readers. GVP1> Agreed, removed the above text # (nit) MP-BGP OLD: MBGP: Even though the Multiprotocol Extensions for BGP-4 (MBGP) [RFC4760] NEW: MP-BGP: Even though the Multiprotocol Extensions for BGP-4 (MP-BGP) [RFC4760] GVP1> Accepted Cheers, Med _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
