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 5. ETR switches to unicast delivery if PIM Hellos not received.
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
