Re: [lisp] [pim] WGLC draft-ietf-pim-join-attributes-for-lisp-03

[Dino Farinacci <[e-mail]>]

> I don't think map-notifies are relevant in the context of this draft. Keep in mind that this draft is written for "pim-signaled" head-end replication. In your "signal-free" draft, map-notifies are the correct message because you are tracking changes in the set of receiver RLOCS and that translates into changes in the merged RLOC set. In this draft, we are tracking changes in source EID location and the proper message for that is an SMR.

I was thinking of using Map-Notifies in this application not in the signal-free one. 

What you do is have the root-xTR register as  a receiver-xTR so when a move occurs the new root-xTR changes which causes the map-server to trigger a Map-Notify to each RLOC in the RLIC-set  because there was an RLOC-set change. 

> The receivers do have map-caches. They

In this data forwarding direction, this is an ETR. ETRs have database-entries which are registered. Used for decapsulation. 

Mao-caches are used for encapsulation. There is no encapsulation in these receiver-ETRs when data flows from a multicast source to the receivers the receiver-ETR supports. 

> have a map-cache entry mapping the source EID to the RLOC of the source XTR.

That is a map-cache entry in the root-ITR not in the ETRs. 

> This is the map-cache entry that we want the SMR to refresh. The creation of this

That is why this is backwards. 

> map-cache was not triggered by traffic. It was triggered by an RPF lookup by PIM in the receiver XTR.

Understand. But it should be called another data structure. Like an RPF data structure, like a RIB is used in normal native routing. 

In any event, if you don't clear up this text, it will be hard for anyone to understand this. 

Dino