> 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. 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. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
