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

[Bharat Joshi <[e-mail]>]

Hi Heidi,

     Thanks for your response. One reply in line.

Regards,
Bharat Joshi
http://bite-the-bytes.blogspot.com/
________________________________________
From: Heidi Ou (hou) [[e-mail]]
Sent: Tuesday, June 03, 2014 10:46 AM
To: Bharat Joshi; Mike McBride; [e-mail]
Subject: Re: [pim] WGLC: draft-ietf-pim-drlb-03

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."

<Bharat>: Ok.

>
>>€ 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.

<Bharat>: I just re-read this section. Couple of things:

* A small typo in "Using the above example, assume R1 and R3 agree on the new GDR, which  is R3", I think it should be 'assume R1 and R2 agree" here.

* I was trying to avoid changing assert metric. Can we do this? Make R1 and R2 delete their forwarding state (or leave the local channels) when they see traffic being received from R3 as well? Then there is no need to change assert messages at all.

thanks
- Heidi




**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***