On 23 Mar 2013, at 12:55 AM, Dino Farinacci wrote: >> We would like to see some discussion on the list for >> draft-arango-pim-join-attributes-for-lisp. The LISP multicast specification >> in RFC6831 defaults to the use of a multicast transport over RLOC space. The >> draft introduces two new attributes to PIM signaling to support unicast >> transport with ingress replication. Slides describing the proposal can be >> found at: >> http://www.ietf.org/proceedings/86/slides/slides-86-lisp-8.pptx > > I have one question and one comment. > >> Unicast transport requires the communication of two additional pieces of >> information in the PIM(S-EID,G)Join message: >> >> 1) An indication that the receiver-ETR wants unicast transport and is not >> additionally joining through native multicast by sending an (S-RLOC,G) Join. >> >> 2) The receiver-ETR RLOC address that should be used as the destination for >> the LISP unicast encapsulated multicast data packets. > > Why can't the two pieces of information be transmitted in one attribute. > Because in both cases, the ETR would be indicating how it wants to receive > encapsulated multicast packets. If the ETR supplies a unicast RLOC, then it > should be implicit that the ETR wants the encapsulation via unicast and if > the ETR supplies a delivery-group address it should should also join with the > deliver-group into the underlay.
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. > 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?). thanks Isidor _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
