Dino, please see inline below.
>> 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? > > We are sending a PIM join and we assume that the upstream LIS xTR is > supporting PIM. This is similar to RFC 6831. If PIM is not supported, the > join message would be ignored. As we mention in section 4 we want to allow a > mixture of multicast and unicast forwarding. > [Lucy] I am thinking that how many PIM protocol instance may run in > this case, one is within a LISP Two. One at all LISP sites (not one per LISP site) and part of the overlay and possibly one in the underlay. [Lucy] Thank, Dino. This is helpful. So the attributes proposed in this draft is used in the first PIM instance, right? These attributes are only used by ETRs to send join/prune msg to ITR (root). > site, one is for LISP underlay network, and one among LISP xTRs, is > this right? PIM protocol instance running for LISP xTRs is a special > version with additional LISP related attributes? When configuring I don’t know what you mean by “additional LISP related attributes”. The LISP xTR runs PIM and sends unicast PIM Join/Prune messages to other xTRs. [Lucy] I mean the attribute is per LISP specific implementation. > PIM protocol on a device, do we need to differ them in configuration? Sorry > to ask these, I have not yet read RFC6831 but understand what you want to > achieve here. That is implementation specific. [Lucy] PIM is a protocol running on top of IGP. Now we have PIM LISP implementation specific. Within a LISP site, PIM has no change; the LISP implementation are only on XTRs. And the details are in RFC6831. And if you are going to do a quality review of this document, you should read RFC 6831. [Lucy] I hear you. >> 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)? > > It is possible to do multicast according to 6831 without these > attributes. As we mention in this Yes, if multicast is in the underlay and reaches every LISP site. But the point is, it may not. Plus this draft can be used when RFC 6831 is NOT used but when draft-ietf-lisp-signal-free-multicast is used so the ITR can know if multicast RLOCs can be used. But the best test to know if a multicast RLOC should be used is to RLOC-probe it and see all the ETRs that reply. Then you know which ETRs can received the encapsulated multicast packet via a multicast underlay. And the ones that don’t, you unicast replicate. This is the case where multicast partially deployed in the underlay. [Lucy] You are the expert on this subject. From the draft text, I am not able to picture these. Regards, Lucy Dino _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
