>> 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. > 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. > 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. And the details are in RFC6831. And if you are going to do a quality review of this document, you should read RFC 6831. >> 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. Dino _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
