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

From: Mike McBride <[email-masked]>
Date: Fri, 23 May 2014 05:10:22 +0000

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

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 23 May 2014 05:17:38 +0000

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

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

---

From: "Heidi Ou (hou)" <[email-masked]>
Date: Wed, 28 May 2014 18:28:32 +0000

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

thanks
- Heidi

On 5/22/14 10:17 PM, "Bharat Joshi" <[email-masked]> wrote:

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

On 5/22/14 10:17 PM, "Bharat Joshi" <[email-masked]> wrote:

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

---

From: Stig Venaas <[email-masked]>
Date: Wed, 28 May 2014 12:50:12 -0700

Hi

I think the draft is in a good shape, but here are some comments.

Please check the nits at
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-pim-drlb-03.txt

As it says, you should use the official IPv4 example addresses in
RFC 5737, not private addresses. Note that for multicast we also
have RFC 6676.

There are also issues with references.

You should write "PIM-SM" rather than "PIM SM" throughout. "PIM-SM"
is what is used in 4601 and also defined at
https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

Use Mbps and Gbps rather than mbps and gpbs?

In 2 you say it is a modification to the PIM protocol. I think it
is more correct to say that it is to PIM-SM.

In 4 it says

    Hello Option.  Besides that, a DR Load Balancing Capability (DRLBC)
    Hello Option, which contains hash algorithm type, is also announced
    by router interfaces which have this specification supported.  Last

I think it should say "enabled" rather than "supported". Perhaps say
"is also announced by the router on interfaces where this specification
is enabled". I think it is important to make this distinction since many
routers might support it, but you may only want to use this mechanism on
certain interfaces on certain routers.

It also says "hop routers who are with the new DRLBC Option". Maybe
phrase this more clearly. "who are with" seems a bit unclear to me.

At end of 4 it says

    A hash algorithm based on the announced Source, Group or RP masks
    allows one GDR to be assigned to a corresponding multicast group, and
    that GDR is responsible for initiating the creation of the multicast
    forwarding tree for the group.

When you hash on source address it would be a GDR for the (S,G), right?
You cold have different GDRs for (S1,G) and (S2,G).

In 4.2 you first describe the hash masks which I think are fairly
independent of the algorithm. But then you describe the use of modulo.
It would be good to make it even clearer what is independent and what
is algorithm specific. Maybe a separate subsection, or a sentence saying
that the rest of this sub section is algorithm specific?

Beginning of 4.3 it says:

    When a last hop PIM router sends a PIM Hello from an interface with
    this specificiation support, it includes a new option, called "Load
    Balancing Capability (DRLBC)".

Typo of "specification". Maybe say with this specification enabled.

5.1 also "enabled" rather than "supports".
State that it only applies to the address family of the source address
of the Hellop IP header.

5.2 State what the length would be for IPv4 and IPv6?
State that all addresses should be of the same family as the Hello IP
header?

End of 6.1:
    Candidate and insert the neighbor's address into the sorted list of
    DRLBGRD Option.

Maybe mention briefly the Router-ID here since not always the neighbor's
address.

6.2
Most of this section is algorithm specific. As I noted in 4.2 it would
be good to make it very clear which parts are algorithm specific. So
good to point that out. Would it make sense to put the algorithm
specific parts in one common section? The last part of 6.2 looks
independent of the algorithm.

    Candidates.  The hasvalue_RP for RP1 172.3.10.10 is 0, matches the
typo                ^^^^^^^^^^^

Use documentation addresses in this section.

7.
Might be good to point out that the values have already been preassigned.

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 30 May 2014 04:32:24 +0000

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) [[email-masked]]
Sent: Wednesday, May 28, 2014 11:58 PM
To: Bharat Joshi; Mike McBride; [email-masked]
Subject: Re: [pim] WGLC: draft-ietf-pim-drlb-03

Hi Bharat,

From: Bharat Joshi

Hi,

Regards,
Bharat

[heidi] Ok

<Bharat>: Ok.

[heidi] done

<Bharat>: Ok.

[heidi] done

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

[heidi] sure.

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

<Bharat>: As mentioned above, I am still not clear about this.

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

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

<Bharat>: Ok.

[heidi] ok.

to

[heidi] ok

<Bharat>: Ok.

<Bharat>:Ok.

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

<Bharat>: Ok.

<Bharat>:Ok.

[heidi] ok

[heidi] yes.

<Bharat>: Ok.

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

[heidi] ok

<Bharat>:Ok.

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

<Bharat>: OK.

<Bharat>: Ok.

<Bharat>: Yeah, Ok.

thanks
- Heidi

---

From: "Heidi Ou (hou)" <[email-masked]>
Date: Fri, 30 May 2014 19:09:16 +0000

Hi Bharat,

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

><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>: As mentioned above, I am still not clear about this.

Please See above. 

><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>: 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>: 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>: 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>: I think it should say "R3 starts to build".

	Corrected. Thanks.

- Heidi