> the draft assumes that PIM works within individual LISP sites but PIM mcast
> transport may not be supported among LISP sites. However the mechanism itself
> does not enforce a unique (unicast or mcast) underlay transport among LISP
> sites. Could some ETRs request unicast transport, other request multicast
> transport? The mechanism requires all LISP xTRs to run PIM protocol, right?
The draft is explaining how PIM messages are sent across the underlay between
xTRs. Not how PIM operates within a LISP site. The way PIM operates within a
LISP site is based on the PIM RFC unchanged.
The draft it solving the hard problem where the underlay neither supports
multicast, partially supports multicast, or fully supports multicast. All these
combinations create the complexity, so it is conveyed from ETRs that unicast
PIM messages to ITRs according to RFC6831 (LISP-Multicast).
> PIM join/prune msg are designed for PIM protocol. These two attributes are
> specifically designed for LISP purpose. Any concern here? From PIM
> perspective, they are optional attributes; are they “MUST” attributes for
> LISP (mcast)?
And the PIM protocol is run (over-the-top) between LISP xTRs.
Gen-art mailing list