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

Hi Jesus,

Have all comments (Dino's) been addressed in this rev? If so we will forward the draft to Alvaro (iesg). Otherwise we will wait until everyone is happy.

thanks,
mike

-----Original Message-----
From: pim [mailto:pim-bounces@ietf.org] On Behalf Of Jesus Arango (jearango)
Sent: Tuesday, June 14, 2016 12:24 PM
To: Dino Farinacci
Cc: lisp@ietf.org; pim@ietf.org; Stig Venaas (svenaas)
Subject: Re: [pim] [lisp] WGLC draft-ietf-pim-join-attributes-for-lisp-03

FYI,

A new version has been uploaded with all the revisions that were brought up during the last-call. Here is the new version:

https://tools.ietf.org/html/draft-ietf-pim-join-attributes-for-lisp-04

Jesus

-----Original Message-----
From: Jesus Arango (jearango) 
Sent: Tuesday, June 7, 2016 11:47 PM
To: 'Dino Farinacci' <farinacci@gmail.com>
Cc: pim@ietf.org; lisp@ietf.org; Stig Venaas (svenaas) <stig@cisco.com>
Subject: RE: [lisp] [pim] WGLC draft-ietf-pim-join-attributes-for-lisp-03

FYI,

I am collaborating with Dino on his comments. We agreed to do some changes and are actively working on them. I will share the changes and publish a new draft version once we reach an agreement on the exact wording to use.

Thanks
Jesus

-----Original Message-----
From: Dino Farinacci [mailto:farinacci@gmail.com] 
Sent: Thursday, June 2, 2016 7:47 PM
To: Jesus Arango (jearango) <jearango@cisco.com>
Cc: pim@ietf.org; lisp@ietf.org; Stig Venaas (svenaas) <stig@cisco.com>
Subject: Re: [lisp] [pim] WGLC draft-ietf-pim-join-attributes-for-lisp-03

> 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

_______________________________________________
pim mailing list
pim@ietf.org
https://www.ietf.org/mailman/listinfo/pim