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

From: Bharat Joshi <[email-masked]>
Date: Mon, 2 Jun 2014 08:02:13 +0000

Hi Heidi,

      Thanks for your replies. I have also removed the text which is no more relevant.

       Please see my response with 'Bharat>':

Regards,
Bharat Joshi
http://bite-the-bytes.blogspot.com/
________________________________________
From: Heidi Ou (hou) [[email-masked]]
Sent: Saturday, May 31, 2014 12:39 AM
To: Bharat Joshi; Mike McBride; [email-masked]
Subject: Re: [pim] WGLC: draft-ietf-pim-drlb-03

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)

Bharat> The text in the draft does not clearly mention that this is specific for (S,G) and so its kind of confusing.

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

<Bharat>: Ok

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

<Bharat>: Ok.

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

<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?

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

<Bharat>: No problem.

- Heidi

>
>
>On 5/22/14 10:17 PM, "Bharat Joshi" <[email-masked]> 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 [[email-masked]] on behalf of Mike McBride
>>[[email-masked]]
>>Sent: Friday, May 23, 2014 10:40 AM
>>To: [email-masked]
>>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
>>[email-masked]
>>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
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/pim
>
>
>
>
>
>On 5/22/14 10:17 PM, "Bharat Joshi" <[email-masked]> 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 [[email-masked]] on behalf of Mike McBride
>>[[email-masked]]
>>Sent: Friday, May 23, 2014 10:40 AM
>>To: [email-masked]
>>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
>>[email-masked]
>>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
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/pim
>

---

From: "Heidi Ou (hou)" <[email-masked]>
Date: Tue, 3 Jun 2014 05:16:00 +0000

Hi Bharat,

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

>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>: But why you want to dictate that? Won't it be easier to left it

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

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 3 Jun 2014 11:13:05 +0000

Hi Heidi,

     Thanks for your response. One reply in line.

Regards,
Bharat Joshi
Sent: Tuesday, June 03, 2014 10:46 AM

Hi Bharat,

<Bharat>: Ok.

<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***

---

From: "Heidi Ou (hou)" <[email-masked]>
Date: Wed, 4 Jun 2014 21:47:42 +0000

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

We are talking about electing a GDR between R1 and R3, for G1. To make it
clear, I will add "for G1" there,
"Using the above example, for G1, assume R1 and R3 agree on the new GDR,
which is R3." 

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

R1 and R2 may not know whether the traffic is really from a GDR or not. So
they don't silently stop forwarding, instead, they are
Still forwarding, until they are sure they are assert losers.

Thanks
- Heidi