Subject: Re: [lisp] draft-arango-pim-join-attributes-for-lisp

From: Dino Farinacci <[email-masked]>
Date: Tue, 26 Mar 2013 16:25:40 -0700

> 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-masked]> 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
>