On 27.03.2013 10:02, Dino Farinacci wrote:
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.
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.
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.
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.
You could also know you have reachability by having say a SAFI 1 route
in BGP for the root RLOC.
Stig
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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
