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

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

Hi Bharat,

I trimmed down the text to focus on the ones need more discussion.


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



>
>€ In section 3, I also did not understand how ECMP helps in this load
>balancing. If there are multiple routers on a LAN in which the source also
>sits, as per PIM, its the DR who is to send the register messages to the
>RP. So I am not sure how ECMP helps here in making other router on this
>LAN to do this instead of the DR?
>
>[heidi] Yes it is the DR that sends the registers.  But the packets are
>[heidi] mostly forwarded natively
>[heidi] down the source trees established by (S,G) joins from downstream
>[heidi] routers.
>
><Bharat>: As mentioned above, I am still not clear about this.


Please See above. 

>
>€ As per RFC 4601, PIM DR is elected for any type of networks so there is
>no need to mention that PIM DR election is done in a multi-access network.
>
>[heidi] I am missing the your point here.
>
><Bharat>: What I was trying to suggest is that this draft does not need
>to mention that a DR election is done in multi-access network. It can
>just refer to RFC 4601.


"multi-access" mentioned here, mainly for describing the scenario the
draft is targeting for.
It would be easy for readers to picture it.

>
>€ In section 4, in sentence "The PIM DR is responsible for sending
>Join/Prune messages to the RP or source.", I think we should mention that
>this is done for the local host's join/leave.
>
>[heidi] That would be redundant. If it is not for local hosts, then it
>[heidi] doesn¹t matter whether the router is a DR or not on the interface
>[heidi] from which a PIM Join/Prune is received.
>
><Bharat>: Exactly, a DR router may or may not send PIM join/prune to RP
>because that will depend upon whether DR is the upstream router or not.
>But in case of local joins, DR has the responsibility to do it and hence
>to make the above statement complete, it will be better to add that this
>is for local joins.


Ok, added "local join".


>
>
>€ In section 4.3, its not clear what will be the contents of first PIM
>hello message of a router coming up? Will it contain LB GDR option or not?
>At that time, it may not know whether its a DR or not. Actually, it will
>assume that its the DR until it receives a hello message from a higher DR
>priority router.
>
>
>[heidi] It depends on the implementation¹s choice whether it considers
>[heidi] itself as a DR when the interface comes up.
>[heidi] The draft doesn¹t intend to dictate that choice. IT just specifies
>[heidi] what to send.
>
><Bharat>: But would it create any interoperability issue? If one router
>assumes that it must come in the first PIM message and another does not
>send it in first PIM message.


If a router assume its DR, it should send out the new GDR option.



>€ 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>: Also, I was just reading the text in this section in version
>03. I think there is a small typo in
><Bharat>: "When R3 comes up online, it is possible that R3 becomes GDR
>for both G1 and G2, hence
><Bharat>: R2 starts to build the forwarding tree for G1 and G2"
><Bharat>: I think it should say "R3 starts to build".

	Corrected. Thanks.



- Heidi



>
>
>On 5/22/14 10:17 PM, "Bharat Joshi" <[e-mail]> wrote:
>
>>Mike, Authors,
>>
>>       I had sent some questions/suggestions on this draft almost a year
>>back.
>>
>>       Here is the link:
>>http://www.ietf.org/mail-archive/web/pim/current/msg02720.html
>>
>>       I am not sure if I missed the response. I am also not sure if
>>these has been addresses in the new revision.
>>
>>Regards,
>>Bharat Joshi
>>http://bite-the-bytes.blogspot.com/
>>________________________________________
>>From: pim [[e-mail]] on behalf of Mike McBride
>>[[e-mail]]
>>Sent: Friday, May 23, 2014 10:40 AM
>>To: [e-mail]
>>Subject: [pim] WGLC: draft-ietf-pim-drlb-03
>>
>>Stig and I feel draft-ietf-pim-drlb-03 is ready for WGLC. The authors
>>have addressed all comments to date. Today starts a two week WGLC, please
>>speak up either way.
>>
>>http://www.ietf.org/id/draft-ietf-pim-drlb-03.txt
>>
>>thanks,
>>mike
>>
>>_______________________________________________
>>pim mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pim
>>
>>**************** 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***
>>
>>_______________________________________________
>>pim mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pim
>
>
>
>
>
>On 5/22/14 10:17 PM, "Bharat Joshi" <[e-mail]> wrote:
>
>>Mike, Authors,
>>
>>       I had sent some questions/suggestions on this draft almost a year
>>back.
>>
>>       Here is the link:
>>http://www.ietf.org/mail-archive/web/pim/current/msg02720.html
>>
>>       I am not sure if I missed the response. I am also not sure if
>>these has been addresses in the new revision.
>>
>>Regards,
>>Bharat Joshi
>>http://bite-the-bytes.blogspot.com/
>>________________________________________
>>From: pim [[e-mail]] on behalf of Mike McBride
>>[[e-mail]]
>>Sent: Friday, May 23, 2014 10:40 AM
>>To: [e-mail]
>>Subject: [pim] WGLC: draft-ietf-pim-drlb-03
>>
>>Stig and I feel draft-ietf-pim-drlb-03 is ready for WGLC. The authors
>>have addressed all comments to date. Today starts a two week WGLC, please
>>speak up either way.
>>
>>http://www.ietf.org/id/draft-ietf-pim-drlb-03.txt
>>
>>thanks,
>>mike
>>
>>_______________________________________________
>>pim mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pim
>>
>>**************** 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***
>>
>>_______________________________________________
>>pim mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pim
>