Subject: Re: [pim] pim-dr-improvement wglc

From: "Holland, Jake" <[email-masked]>
Date: Mon, 14 Jan 2019 22:07:46 +0000

Hi,

I think the extension is a good idea and that this doc gives a good
explanation of how it works. However, I think there’s some issues that
should be addressed before publication as a Standards Track RFC.

Major issues:
1. The security considerations section seems too thin. (The complete
contents of the section are “For general PIM Security Considerations.”)

1.a. I think there are some security implications because of
the new stickiness in the DR election process. For instance, in
https://tools.ietf.org/html/rfc5015#section-5.1.1 when describing what
happens when a DR has been impersonated, it implies there’s a
mitigation (“[The impersonated] node typically will be able to detect
the anomaly and, possibly, restart a new election.”)

But because the DR is more sticky with this new extension, I think the
kind of temporary disruption would have a more permanent effect that
the impersonated node could not mitigate. I might be wrong about that
being actually more dangerous, but it worries me that there’s no
mention of issues like these in the security considerations section.

I think for this point, it might be enough to just say that the
election process may be more vulnerable to temporary disruption because
the DR election is more persistent, and that this increases the
importance of using source authentication to avoid DoS from malicious
activity.

1.b. I think this probably should mention that BFD security
considerations are applicable also, or the considerations for whatever
DR failure detection mechanism is used.

2. There should probably be a reference to BFD, and perhaps other
fast failure detection mechanisms, if they’re recommended.

More generally, it seems to me that the speed of DR failure detection
is of critical importance in using this mechanism, so the one brief
mention (which doesn't explain the pros and cons of faster detection or
make any recommendations about technologies to use) seems like it
skims past a key point without explaining it in depth.

Minor/editorial issues:

1. In section 3.2, it probably should talk about the IP version in the
PIM message, instead of IP version supported by the network. The way
it’s written, it seems to make it impossible to run a dual-stacked
network with 2 instances of PIM, but I don’t think that’s the intent.

2. Should the reference to 2328 be informative instead of normative? It
seems like it’s only used as an example.

3. The IANA considerations section should follow the guidelines from
RFC 8126 section 1.3 (exact name of the registry, for instance). It
also seems useful to make 2 separate values, TBD1 and TBD2 instead of
using TBD for both.

4. “SW” is not defined in the diagram in Figure 1. I think the 2 SW
boxes are Layer 2 switches on the same LAN, but I’m not certain.

5. In section 4, I think "MUST not" in the last paragraph should have
NOT capitalized?

6. I don't understand the meaning of "The treatment" as the title
for section 4.5.

7. There are a lot of English language nits. I saw that Greg covered
several of them, so I’ll just mention the ones I saw in sections he
didn’t cover:

section 1:
“can be adjust to” -> “can be adjusted to”
“Still, may multicast packets” – should this be “many” instead of “may”?
“new comers” is one word (this appears several times in the doc)
I’m not certain, but I think each time the word “Ethernet” is used, “LAN” was intended?
“new comers which has a higher”: has->have

... (skipping sections Greg Mirsky covered) ...

section 4.5:
“are start to work on the same time”
“when a new router start to work” -> starts to work
“fails or manually adjustment” -> fails or is manually adjusted

I had to stop early before finishing a catalogue of all the rest of the
issues I could find, but because of the very high density of nits, I’ll
suggest it might be a good idea to try using an English-language
proofreading service that works with technical documents.

This is not an endorsement, and I’ve never used their services, but as
an example of the kind of service I mean, here’s one I found in a few
moments with a search engine:
https://www.proof-reading-service.com/

Thanks for this work, it seems like a useful extension.

Best,
Jake

From: Michael McBride <[email-masked]>
Date: 2019-01-08 at 10:29
To: "[email-masked]" <[email-masked]>
Subject: [pim] pim-dr-improvement wglc

Happy New Year!

Today begins a two week wglc for draft-ietf-pim-dr-improvement-06. In Bangkok, 4 people indicated that they had read the draft and each agreed it’s ready for wglc. Let’s please read the draft one more time and confirm, on this list, that it’s ready to be sent to iesg.

https://tools.ietf.org/html/draft-ietf-pim-dr-improvement-06<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dpim-2Ddr-2Dimprovement-2D06&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=fIcyCL8wIA2EPznG-rnydT8d8lxOTVQr2JCmbTZQlow&s=6J6K4ZX_93Ir466HVBf_fg7Kc669SUvwl-fLx0v0KN8&e=>

thanks,
mike

---

From: Stig Venaas <[email-masked]>
Date: Tue, 15 Jan 2019 08:20:24 -0800

Hi

I overall agree with the other reviewers' comments. One high level
concern I think needs to be addressed in the draft is how to detect
that other neighbors support the mechanism, and how to behave if not
all routers support it.

One way of detecting support for the mechanism would be to check if
neighbors announce the new options. In that case, what should be the
content of the options if not all neighbors support it. Also, is it OK
to use the mechanism if the neighbors not supporting it have a low DR
priority, or is it better to require that all neighbors support it?
What should be the behavior once all neighbors support it (a
non-capable neighbor went away), or if a non-capable neighbor comes
up?

Section 4.2 should talk about primary address, not Router ID.

Regards,
Stig

On Mon, Jan 14, 2019 at 2:08 PM Holland, Jake <[email-masked]> wrote:
> https://tools.ietf.org/html/draft-ietf-pim-dr-improvement-06
>
>
>
> thanks,
>
> mike
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 17:09:20 +0800 (CST)

Hi Greg, Jake, Stig,

Thank you very much for your careful review and suggestion!

A new version of this draft has been submitted.

The nits you mentioned are fixed. And I add more description in Compatibility section and Security Considerations section.

Appreciate for your more view!

PS. It seems like the previous email has been held for some reasons, so I resend this email. Sorry for the duplicate emails.

Best regards,

Sandy

原始邮件

发件人：StigVenaas <[email-masked]>
收件人：Holland, Jake <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2019年01月16日 01:11
主 题 ：Re: [pim] pim-dr-improvement wglc

Hi

Regards,
Stig

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 16:56:57 +0800 (CST)

Hi Greg, Jake, Stig,

Thank you again for your more view!

Best regards,

Sandy

A new version of I-D, draft-ietf-pim-dr-improvement-07.txthas been successfully submitted by Zheng(Sandy) Zhang and posted to theIETF repository.Name:        draft-ietf-pim-dr-improvementRevision:    07Title:        PIM DR ImprovementDocument date:    2019-01-17Group:        pimPages:        13URL:            https://www.ietf.org/internet-drafts/draft-ietf-pim-dr-improvement-07.txtStatus:         https://datatracker.ietf.org/doc/draft-ietf-pim-dr-improvement/Htmlized:       https://tools.ietf.org/html/draft-ietf-pim-dr-improvement-07Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-pim-dr-improvementDiff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-pim-dr-improvement-07

原始邮件

Hi

Regards,
Stig

---

From: Michael McBride <[email-masked]>
Date: Fri, 25 Jan 2019 23:27:07 +0000

Does this latest version address all of the comments from Greg and Jake? If so we will forward it on.

Thanks
mike

From: pim [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 17, 2019 1:09 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [pim] pim-dr-improvement wglc

Hi Greg, Jake, Stig,

Best regards,

Sandy

原始邮件
发件人：StigVenaas <[email-masked]<mailto:[email-masked]>>
收件人：Holland, Jake <[email-masked]<mailto:[email-masked]>>;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2019年01月16日 01:11
主 题 ：Re: [pim] pim-dr-improvement wglc
Hi

Regards,
Stig

On Mon, Jan 14, 2019 at 2:08 PM Holland, Jake <[email-masked]<mailto:[email-masked]>> wrote:
> From: Michael McBride <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pim

---

From: <[email-masked]>
Date: Sat, 26 Jan 2019 12:09:41 +0800 (CST)

Hi Mike,All the comments from Greg and Jake have been addressed except for if the pseudocode should be provided. My concern is that it may not be the must because most of the parts is the same. But more suggestions about it are welcomed.A spelling nit will be fixed in next version.Thanks,Sandy 发自我的zMail 

原始邮件

发件人:MichaelMcBride<[email-masked]>

收件人:张征00007940;gregimirsky<[email-masked]>;jholland<[email-masked]>;stig<[email-masked]>;

抄送人:pim<[email-masked]>;

日期:2019-01-26 07:27:07

主题:RE: [pim] pim-dr-improvement wglc

 

 
Thanks

mike

 

 

Hi Greg, Jake, Stig,

 

 

 

 

 Best regards,

 Sandy

 
 原始邮件

 

 

 

 
日 期 ：2019年01月16日 01:11

 

Hi

 
 
 Regards,
 Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 28 Jan 2019 09:33:03 -0800

I'll have another look myself. I only mentioned the more high level
concerns I had in my previous email. But it might all be good. Let me
see.

Stig

On Fri, Jan 25, 2019 at 8:09 PM <[email-masked]> wrote:
>
> Hi Mike,
>
> All the comments from Greg and Jake have been addressed except for if the pseudocode should be provided. My concern is that it may not be the must because most of the parts is the same. But more suggestions about it are welcomed.
> A spelling nit will be fixed in next version.
>
> Thanks,
> Sandy
>
>
>
> 发自我的zMail
>
> 原始邮件

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 29 Jan 2019 09:03:47 +0800

Hi Mike,
I believe that my comments got addressed by the new version. I confirm my
support to adopt this draft by PIM WG.

Regards,
Greg

On Sat, Jan 26, 2019 at 7:27 AM Michael McBride <[email-masked]>
wrote:

> *From:* pim [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Thursday, January 17, 2019 1:09 AM
> *To:* [email-masked]; [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [pim] pim-dr-improvement wglc
>
>
>
> Hi Greg, Jake, Stig,
>
>
>
> The nits you mentioned are fixed. And I add more description in
> Compatibility section and Security Considerations section.
>
> PS. It seems like the previous email has been held for some reasons, so I
> resend this email. Sorry for the duplicate emails.
>
>
>
> Best regards,
>
> Sandy
>
>
>
> 原始邮件
>
> *发件人：*StigVenaas <[email-masked]>
>
> *收件人：*Holland, Jake <[email-masked]>;
>
> *抄送人：[email-masked] <[email-masked]>;
>
> *日 **期 * *：*2019年01月16日 01:11
>
> *主 **题 **：Re: [pim] pim-dr-improvement wglc*
>
> Hi
>

---

From: Stig Venaas <[email-masked]>
Date: Tue, 29 Jan 2019 10:50:04 -0800

Hi

Here are my comments on revision 7.

There should be no references in the abstract.

In the abstract it says:
   failure.  This document provides an extension to the existing
   protocol which would improve the stability of the PIM protocol with
   respect to traffic loss and convergence time when the PIM DR is down.

Shouldn't it say "going down" rather than "is down"? Or maybe better,
"when the PIM DR role changes"?

In section 4, it says "0x00000000" for IPv4. Wouldn't it be better to
use 0.0.0.0?

In 4.1 it says:
4.1.  Deployment Choice

   DR / BDR election SHOULD be handled in two ways.  Selection of which
   procedure to use would be totally dependent on deployment scenario.

I think it might be better to say that deploying this draft is optional.
One can choose to use what 7761 specifies, or what is specified here.
Basically there are not 2 options described in this draft, but rather
1 option, and one can choose whether to use it.

In 4.2 I find this paragraph hard to read:
   (4) If Router X is now newly the Designated Router or newly the
   Backup Designated Router, or is now no longer the Designated Router
   or no longer the Backup Designated Router, repeat steps 2 and 3, and
   then proceed to step 5.  For example, if Router X is now the
   Designated Router, when step 2 is repeated X will no longer be
   eligible for Backup Designated Router election.  Among other things,
   this will ensure that no router will declare itself both Backup
   Designated Router and Designated Router.

It is not clear what router X is here.

In 4.6:
DR/BDR function also can be used in source side that multiple routers

This makes it sound like it is optional. Better to say "DR/BDR function
is also used".

Section 5:
BDR carried in hello message SHOULD be set to zero.

Why not a MUST?

Section 6:
I don't think this section is needed. It should be sufficient to make
it clear that this solution reduces packet loss. But if you keep it,
you should not use normative language like "SHOULD". It's better to
say with just regular text that this solution will help.

Section 8:
It would be good to specify the exact option names here. Also that
the strings TBD1 and TBD2 should be replaced by the assigned values.

Regards,
Stig

On Mon, Jan 28, 2019 at 5:03 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Mike,
> I believe that my comments got addressed by the new version. I confirm my support to adopt this draft by PIM WG.
>
> Regards,
> Greg
>
> On Sat, Jan 26, 2019 at 7:27 AM Michael McBride <[email-masked]> wrote:
>>

---

From: <[email-masked]>
Date: Thu, 31 Jan 2019 10:44:01 +0800 (CST)

Hi Stig,

Thank you very much for your review! :-)
Please see my answer below.

Thanks,
Sandy

------------------原始邮件------------------
发件人：StigVenaas <[email-masked]>
收件人：Greg Mirsky <[email-masked]>;
抄送人：Michael McBride <[email-masked]>;张征00007940;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年01月30日 02:50
主 题 ：Re: [pim] pim-dr-improvement wglc
Hi

In the abstract it says:

Shouldn't it say "going down" rather than "is down"? Or maybe better,
"when the PIM DR role changes"?
------[Sandy]: will modify to "when the PIM DR role changes"
In section 4, it says "0x00000000" for IPv4. Wouldn't it be better to
use 0.0.0.0?
------[Sandy]: will modify it.

In 4.1 it says:
4.1.  Deployment Choice

------[Sandy]: If "Depend on the deployment scenario, network administrator can choose the DR election defined in RFC7761, or the election function defined in this document." is better?

It is not clear what router X is here.
------[Sandy]: If it is better that we replace "Router X" by "a/the router"?

In 4.6:

This makes it sound like it is optional. Better to say "DR/BDR function
is also used".
------[Sandy]: will modify it.

Section 5:

Why not a MUST?
------[Sandy]: will fix it.

Section 6:
------[Sandy]: will delete it.

Section 8:
It would be good to specify the exact option names here. Also that
the strings TBD1 and TBD2 should be replaced by the assigned values.
------[Sandy]: will modify it.

Regards,
Stig

On Mon, Jan 28, 2019 at 5:03 PM Greg Mirsky <[email-masked]> wrote:
>> From: pim [mailto:[email-masked]] On Behalf Of [email-masked]..cn