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

[Bharat Joshi <[e-mail]>]

Hi Heidi,

      Thanks for your response. Please see my response in line with '<Bharat>:'

Regards,
Bharat Joshi
http://bite-the-bytes.blogspot.com/
________________________________________
From: Heidi Ou (hou) [[e-mail]]
Sent: Wednesday, May 28, 2014 11:58 PM
To: Bharat Joshi; Mike McBride; [e-mail]
Subject: Re: [pim] WGLC: draft-ietf-pim-drlb-03

Hi Bharat,

Thanks for your comments, sorry to reply this late, but
we have made quite a few changes since -02- (latest is -03-),
especially in section 6.2 and 6.3.

Please find reply inline, search for [heidi]



From: Bharat Joshi
Sent: Friday, June 28, 2013 4:09 PM
To: pim at ietf.org
Subject: Few questions/suggestion on DR Load Balancing draft

Hi,

       I just read through the DR Load Balancing draft. I have few
questions/suggestion below.

Regards,
Bharat

€ In Abstract, s/as an Ethernet/as Ethernet/g. This seems to be at couple
of places.


[heidi] Ok

[heidi] I will try to fix some of the obvious errors and follow up with
[heidi] chairs to see how we can get such a review done.
[heidi] I remember we have a review specifically for the proper and
[heidi] accurate use of the English language in an I-D.

<Bharat>: Ok.

€ Are 'first hop network' or 'last hop LAN' a well known term? Will it be
easy for people to understand that this is being talked from multicast
source perspective? Can we call them directly connected LAN in both the
cases?

[heidi] They are well-known.  Googling ³pim first hop² will generate
reference from several different sources.



€ In Abstract, s/is operated in PIM SM/is operating in PIM SM/g. This is
at least at two places.

[heidi] done


€ In Abstract, in following sentence:

On the last hop network, the PIM DR is responsible for tracking local
multicast listeners and forwarding traffic to these listeners if the group
is operated in PIM SM/SSM/DM.

Should we mentioning BIDIR-PIM as well in this list? Or such a group is
treated differently?


[heidi] The concept of PIM-DR is not relevant for Bidir-PIM.  In
[heidi] Bidir-PIM, it is the DF that handles forwarding.

<Bharat>: Ok.

€ In Abstract, s/can be distributed to and handled among these/can be
distributed among these/

[heidi] done


€ In GDR definition, it talks about that GDR is responsible for a group.
Does this mean that a single GDR will be responsible for all channels
(S,G) for a given group but different sources?

[heidi] Which flow, i.e., (S,G), a GDR is responsible for depends on the
[heidi] hash function.

<Bharat>: I looked at the text in current draft. It looked ok to me.

€ s/process received new PIM Hello/process new PIM Hello/

€ In Introduction, in following sentence:

According to [RFC4601], R1 will be responsible for forwarding to the last
hop LAN.

       Can we replace this sentence by something similar to a sentence
from RFC 4601, section 6.1.1 point 2. The sentence is as follows:

The designated router on a LAN is (in the absence of asserts) responsible
for forwarding traffic to that LAN on behalf of any local members.


[heidi] sure.


€ There may be a mix of local hosts as well as downstream routers in a
network scenario. Do we still call this the last hop LAN? I guess yes and
I think there can still be GDR candidate and this draft can apply. Right?
I think this is not coming out well in the draft. So please add/update
some text to reflect this.

[heidi] The draft should still apply in the scenario described.

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

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

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

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

€ In section 4, para 1, I think it should be enough if the text suggest
that PIM DR election is done as per RFC 4601 instead of describing the
algorithm here.

[heidi] We will keep the text. Another reviewer might wish to have the
[heidi] additional description.

<Bharat>: Ok.


€ s/routers support this specification/routers which support this
Specification/

[heidi] ok.

€ In section 4, can we reword the following sentence:

Last hop routers who are with the new LBC TLV and with the same DR
priority as the PIM DR are GDR Candidates.

to

Last hop routers which supports the 'Load Balancing Capability' PIM hello
option and uses the same DR priority as the PIM DR, are considered to be
GDR Candidates.

[heidi] ok

€ In section 4, last para, can we clearly mention that we are referring to
groups joined by local members only.

[heidi] As mentioned early, The context of this draft is for directly
[heidi] attached host. We are not modifying any behavior of a PIM router
[heidi] when it receives a PIM Join/Prune.

<Bharat>: Ok.

€ I think section 4.2 should be divided into two, one that defined hash
mask and another that defines the hash function.

[heidi] it is not a large paragraph, we will keep it as is.

<Bharat>:Ok.

€ Apart from the hash value/function, cannot an administrator configure
the mapping statically? This way, an administrator will have more control
on which channel is registered by which DR and also, he won't need these
new hello options. I agree that such a thing will work only if all vendors
provide such a mean to the administrators.

[heidi] Correct. We are trying to reduce unnecessary configuration, and
[heidi] reduce the possibility of inconsistency.



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

€ In section 5.2, should we be using encoded format defined in RFC 4601
for GDR addresses or using it in native format is fine?

[heidi] The encoded format doesn¹t handle non-contiguous mask.

<Bharat>: Ok.

€ What is the idea of sending the masks from PIM DR to other routers? Why
cannot they be configured in all the routers?
[heidi] yes, but we want to use the protocol to handle this automatically,
and consistently.

<Bharat>:Ok.

€ s/When an IGMP join is received/When an IGMP/MLD join is received/
€ s/a neighbor Hello with/a PIM Hello with/

[heidi] ok


€ What happens when a PIM router supporting this new options times out in
PIM DR router?

[heidi] Then another router will become the DR and take over the
[heidi] responsibility.




€ Does PIM DR insert its own address as well in the neighbor's address
into the LBGRD TLV list?

[heidi] yes.

€ In section 6.2, first para talks about router R1. Is it referring to
figure 1?

[heidi] It's actually just referring to PIM DR. I will remove it,
[heidi] just saying "PIM DR".

<Bharat>: Ok.

€ In section 6.2, should not we mention what a GDR candidate does when a
PIM hello from PIM DR is received? I think few last paras at the end of
this section should be in the front. Please check.

[heidi] Could you please be more specific about what is missing and
[heidi] suggest text?

<Bharat>: I am sorry but I am not able to recall this.

€ s/from a non-DR PIM router/from a PIM router which is not DR/

[heidi] ok

€ In section 6.2, its not clear if the hash is calculated only for 'X' or
for all the GDR available in the list. I think it needs to be calculated
for all of them and then if hash is highest for 'X', its selected,
otherwise not.

[heidi] In the latest version, -03-, the hash value is computed for X
[heidi] only. If the hash value matches the ordinal number assigned to X, X
[heidi] will be the GDR.

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

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

€ What happens when a new router comes up which becomes the DR but does
not support this new PIM hello option?

[heidi] First of all, the draft suggest an administrator to configure DR
[heidi] priority properly to make sure
[heidi] such a thing doesn¹t happen (and therefore fully take advantage of
[heidi] the idea
[heidi] described by this draft). If the unfortunately happens, then the
[heidi] lan behaves
[heidi] according to RFC4601. There will be no load balancing.

<Bharat>: OK.

€ What is the need of sending out the list of GDR by PIM DR to other
routers? Other routers can anyway figure this out because they also
receive the PIM hello from other routers. Right?

[heidi] Yes, but that's not as resilient.

<Bharat>: Ok.

€ In section 8, "PIM DR Load Balancing Hello message", does not look right.

[heidi] how about "the new DR Load Balancing PIM Hello Options"?

<Bharat>: Yeah, Ok.


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