> As Jesus explained two separate attributes were defined for added > flexibility. For example it is possible to specify the receiver-ETR RLOC even > in the case that multicast transport is used. It may be needed to specify a > target for SMRs. > As for allowing the receiver-ETR to specify a multicast delivery group > instead of a unicast RLOC, is that model desired? A different mechanism would > be required as the receiver-ETRs would not be capable of coordinating to pick > the same group.
This is how multiple ETRs at different receiver sites could use a delivery-group: (1) When (S-EID, G) join state is created in an ETR and it is using RFC 6831 signaling and using the join-attributes from draft-arango-pim-join-attributes-for-lisp, The ETR can do a mapping database lookup on (S-EID,G). (2) The RLOC returned can be a multicast-delivery group, and group is added to the join-attribute. (3) The ITR or a network management system can write the (S-EID,G)->DG mapping to the mapping database. > >> And the comment, even if the ETR supplies a delivery-group and does join the >> underlay, packets encapsulated in multicast may still not reach the ETR. So >> to generally solve this problem, there needs to be more machinery so the ETR >> can tell if there is multicast connectivity (per address-family) from the >> ITR. > > > The information on whether the root-ITR has multicast connectivity can be > provided through the registered mapping (as an LCAF attribute?). Right. But that only solves part of the problem. If you solve the whole problem you won't need the mapping solution. What if 3 ETRs, all connected to a multicast access network and the ITR also connected to a multicast access network are connected together by a non-multicast network. Just because the edges have the connectivity, doesn't mean the edges WILL GET multicast packets delivered. However, if the non-multicast part of the network can tunnel to those access networks, then it is providing that multicast connectivity is contiguous. We have to make a architecture decision if the edges just say they can get multicast and the core makes sure it does. Versus the edges figuring out they cannot get multicast and they take their own action (requesting head-end unicast replication). Can we have a discussion about this? It will bring up the same arguments and points when the edges have IPv6 but the core does not. So here is another example where the core does have multicast. But the edges are only doing IPv6 multicast and can get IPv6 multicast from their access providers but the core only supports IPv4 multicast. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
