> Can we do something along the following lines? > > 1. ETR performs mapping lookup on S-EID to get multicast delivery group DG. > (As Dino suggests) > 2. ETR joins (S-EID, G) and (ITR-RLOC, DG) > 3. ITR sends (ITR-RLOC, ETR-RLOC) unicast LISP encapsulated PIM Hello > 4. ETR remains on delivery tree as long as PIM Hellos are received
If PIM hellos are received, all it means is that unicast packets can make it to the ETR (from the ITR). Did you mean to say "PIM Hellos are sent from ITR with (ITR-RLOC, DG)"? > 5. ETR switches to unicast delivery if PIM Hellos not received. So I would not use PIM Hellos. I would use RLOC-probes. We can call these multicast RLOC-probes. That way, all ETRs can detect if the mapping of the ITR changed. And, just maybe, the ITR could CHNAGE the delivery group and signal to everyone. Also, I think the ITR would want to know if an ETR can receive the multicast encapsulated packet. Some will and others will not, so the ITR will have to do both unicast and multicast encapilcating. We could also use this mechanism for the ITR to change a public key perhaps, for rekeying, but that is another matter (i.e. I want to wake up the security geeks on this list - LOL). But Jesus, we have to be careful going down this design path. Since join latency will be relatively high by having multiple RTT events and timeouts before getting data to the ETRs. The questions is if you err on duplicates by head-end replicating while the ITR detects the ETRs can receive on DG. Dino > > Jesus > > >> -----Original Message----- >> From: Dino Farinacci [mailto:[email protected]] >> Sent: Wednesday, March 27, 2013 10:02 AM >> To: Isidoros Kouvelas (kouvelas) >> Cc: [email protected]; Jesus Arango (jearango); Stig Venaas >> Subject: Re: [lisp] draft-arango-pim-join-attributes-for-lisp >> >>> 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
