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

From: Isidoros Kouvelas <[email-masked]>
Date: Thu, 21 Mar 2013 12:40:53 +0200

Hello,

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

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.

The draft is introducing the "Transport" and "Receiver RLOC" PIM Join/Prune attributes to carry the additional required information in LISP encapsulated (S-EID,G) Join/Prune PIM messages.

The draft was presented in Orlando in the PIM working group but due to agenda time limitations it was not presented in LISP. The conclusion in the PIM WG is that they have no problem in adopting the draft as long as the LISP WG thinks that it makes sense and is useful. We are therefore looking for input to move this forward.

Note that the draft is incorrectly labeled as standards track. It will be fixed to reflect that it is experimental in the next revision.

thanks
Isidor

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 22 Mar 2013 15:55:24 -0700

>  http://www.ietf.org/proceedings/86/slides/slides-86-lisp-8.pptx

I have one question and one comment.

> 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

---

From: Isidoros Kouvelas <[email-masked]>
Date: Wed, 27 Mar 2013 08:23:16 +0200

> 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 suppli…

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…

The information on whether the root-ITR has multicast connectivity can be provided through the registered mapping (as an LCAF attribute?).

thanks
Isidor

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 27 Mar 2013 10:02:18 -0700

> 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 ca…

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.

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 27 Mar 2013 11:15:50 -0700

> 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

If PIM hellos are received, all it means is that unicast packets can make it to the ETR (from the ITR). Did you mean to say "PIM Hellos are sent from ITR with (ITR-RLOC, DG)"?

> 5. ETR switches to unicast delivery if PIM Hellos not received.

So I would not use PIM Hellos. I would use RLOC-probes. We can call these multicast RLOC-probes. That way, all ETRs can detect if the mapping of the ITR changed. And, just maybe, the ITR could CHNAGE the delivery group and signal to everyone. Also, I think the ITR would want to know if an ETR can receive the multicast encapsulated packet. Some will and others will not, so the ITR will have to do both unicast and multicast encapilcating.

We could also use this mechanism for the ITR to change a public key perhaps, for rekeying, but that is another matter (i.e. I want to wake up the security geeks on this list - LOL).

But Jesus, we have to be careful going down this design path. Since join latency will be relatively high by having multiple RTT events and timeouts before getting data to the ETRs. The questions is if you err on duplicates by head-end replicating while the ITR detects the ETRs can receive on DG.

Dino

> 
> Jesus
> 
> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:[email-masked]]
>> Sent: Wednesday, March 27, 2013 10:02 AM
>> To: Isidoros Kouvelas (kouvelas)
>> Cc: [email-masked]; 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.
>> 
>> (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).
>> 
>>>> 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
>> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 27 Mar 2013 11:16:39 -0700

> You could also know you have reachability by having say a SAFI 1 route
> in BGP for the root RLOC.

And what if BGP is not used? What if the xTR is a mobile phone?

Dino

---

From: Isidoros Kouvelas <[email-masked]>
Date: Thu, 28 Mar 2013 15:09:37 +0200

Dino,

I understand that the problem you describe is a concern but I do not think it is related to the proposal in the draft. The way to know if you have contiguous multicast connectivity is to use a separate routing topology for your multicast RPF information than what you use for unicast. If multicast specific information is not available then the risk of connectivity gaps is always present even without LISP.

Isidor

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 28 Mar 2013 07:23:03 -0700

> Dino,
> 
> I understand that the problem you describe is a concern but I do not think it is related to the proposal in the draft. The way to know if you have contiguous multicast connectivity is to use a separate routing

Agree, we have moved the conversation to solving another problem. One that needs to be solved. If you have a hammer and no nails, you can't nail anything in but you can use the hammer for some other purpose.

> topology for your multicast RPF information than what you use for unicast. If multicast specific information is not available then the risk of connectivity gaps is always present even without LISP.

Right, but the spirit of overlays is to solve such problems.

Dino

---

From: "Jesus Arango (jearango)" <[email-masked]>
Date: Wed, 27 Mar 2013 17:30:27 +0000

Jesus

---

From: Stig Venaas <[email-masked]>
Date: Wed, 27 Mar 2013 10:59:53 -0700

> (3) The ITR or a network management system can write the (S-EID,G)->DG mapping to the mapping database.

Maybe we can allow this with the attribute in this draft. I'm a bit
concerned about receivers possibly trying to join another DG though.

Stig