Subject: Re: [pim] AD Review of draft-ietf-pim-drlb-10

From: Alvaro Retana <[email-masked]>
Date: Mon, 9 Sep 2019 14:27:48 -0700

On August 27, 2019 at 5:54:48 PM, Stig Venaas ([email-masked]) wrote:

Stig:

Hi!

...

> [major] Is there a possibility that the assigned GDR for a specific
multicast state can't fulfill its duties? This document assumes that all
the GDRs are able to service all states...but that may not be true. Because
every GDR candidate calculates who the GDR is for a specific state, it may
never know what an alternate GDR is not able to forward traffic. [Does this
make sense?]

It is assumed that a router is only configured as GDR if it is
expected to have the necessary connectivity etc to fulfill its role.
This is no different than expecting today that any router elected as
the DR has the necessary connectivity. Implementations could
potentially have some ways of automatically decrease the priority in
failure scenarios to avoid being the DR. This is not specific to DRLB
though.

True.

I’m not sure if we want to point this fact out…but because it is not
different than a DR…. I’ll leave it up to you.

> [minor] Can you provide any guidance on how to configure the hash masks?
The example below shows a mask of 0.0.255.0, which seems both "unnatural"
(for the average person used to set masks) and very specific (in order for
N to have a specific value). Maybe it's just me, but I would have set the
mask to something similar to 255.255.0.0/0.0.255.255. Guidance should be
added to §8 (Manageability Considerations).

The reason for allowing such masks rather than just prefix lengths is
to allow load-balancing regardless of how service providers utilize
their space. I will try to think of examples. It would allow for
ensuring that certain groups always are hashed to the same router
(that the hash value computed is exactly the same for the groups).
That is, H(G1) == H(G2) if G1 and G2 are the same after the mask is
added. Hence the same router will be selected as the GDR for both G1
and G2.

Allowing that type of mask is ok.  Examples are good.  I would like to see
text about (maybe as part of an example) how some masks will provide better
utilization...

> [major] What does "provide" mean in this context? I guess that it means
that if no hash mask is configured, then the default should be used. Is
that correct?
>
> [major] When would an implementation not provide those masks? IOW, why
aren't you using MUST?

Just using default masks would be sufficient for most deployments.

Ok…so s/SHOULD/MUST, right?

s/SHOULD provide masks with default values/MUST provide masks with default
values

...

It will take a while for us to revise the document.

Ok.

Thanks!!

Alvaro.