> Dino, > > One reason for two attributes is flexibility. For example, You could send > the receiver RLOC attribute on the upstream neighbor field, and the > transport mode attribute on each individual source. This would allow > requesting multicast transport for some sources and unicast transport for > others without having to repeat the receiver RLOC address for each source. > > Jesus
Okay, thanks for the response Jesus. That makes perfect sense. Dino > > > > > On 3/22/13 3:55 PM, "Dino Farinacci" <[email protected]> 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. >> >> 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
