Re: [pim] WGLC: draft-ietf-pim-drlb-03

["Heidi Ou (hou)" <[e-mail]>]

Hi Bharat,



On 6/2/14 1:02 AM, "Bharat Joshi" <[e-mail]> wrote:


>>€ In section 3, I did not get what 'load balancing' are we talking about
>>in case of 'first hop routers'?
>>
>>[heidi] It is referring to the common implementation that when a
>>downstream
>>[heidi] router has multiple upstream neighbors that are equal cost as
>>[heidi] determined by IGP,
>>[heidi] it will ³load balance² the joins when choosing an upstream
>>[heidi] neighbor.
>>
>><Bharat>: I still did not fully get this. Is this for source or a RP?
>>Won't there be multiple multicast stream get forwarded to the LAN and
>>then assert will choose one forwarder. Why would we want to do this?
>
>
>"load balancing" for source. When a downstream sends PIM Join towards
>Upstream (including FHR), the downstream looks at its unicast RIB. If
>There are multiple ECMP path to reach the source, implementation
>Usually do load balancing automatically for each RIB lookup. Say if
>Downstream has p1,p2, p3, 3 paths to reach S1, it will use p1 for
>(S1,G1), p2 for (S1,G2), and P3 for (S1,G3)
>
>Bharat> The text in the draft does not clearly mention that this is
>specific for (S,G) and so its kind of confusing.


Since this is on FHR, it's normally a source tree. How about

"it will load balance the source tree joins when choosing an upstream
neighbor."



>
>>€ In section 6.3, in case of PIM assert, should not we override the
>>existing Assert algorithm completely and suggest that the winner should
>>be
>>selected based on the currently selected GDR?
>>
>>[heidi] Could you please elaborate the reasons why 6.3 is insufficient in
>>[heidi] this case?
>>
>><Bharat>: What I was trying to ask is that is there really a need to
>>suggest modifications in assert mechanism. Instead, let the assert
>>mechanism use the existing algorithm as it is. The only thing we need is
>>that we would want to reduce the traffic loss which can be avoided by
>>making R1 and R2 not stopping the forwarding.
>
>
>But we are trying to forward traffic via GDR, and that can't be done by
>current Assert algorithm.
>
><Bharat>: But why you want to dictate that? Won't it be easier to left it
>to Assert?
>


Are you suggesting all routers should select GDR as Assert winner?

We can only enforce new rule on routers supporting the draft. For those
don't
Understand GDR, the Assert computation have to be done with existing
algorithm.

thanks
- Heidi