[lisp] Mohamed Boucadair's Discuss on draft-ietf-lisp-rfc6831bis-07: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

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).

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

# 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.

# 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.

## 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.

# 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.

# 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.

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

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

## to what extent there are deployments that rely on such multiple RLOC
allocation scheme?

## is this “possible solution” something that can be really recommended?

# 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.


----------------------------------------------------------------------
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.

# Changes vs. 6831

Please include a description of the main changes vs. 6831. This can be added in
an appendix.

# 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.

# (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]

Cheers,
Med