Re: [pim] RFC 4601bis

Re: [pim] RFC 4601bis - erratas

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Wed, 16 March 2011 03:08 UTC

From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "'Stig Venaas (svenaas)'" <svenaas@cisco.com>, "'Rishabh Parekh (riparekh)'" <riparekh@cisco.com>, 'Vero Zheng' <verozheng@huawei.com>, "pim@ietf.org" <pim@ietf.org>
Date: Tue, 15 Mar 2011 23:03:45 -0400
Thread-Topic: RFC 4601bis - erratas
Thread-Index: Acvc3Pmh0jKTMWyVS8GQe9fAswh/5wAAU6tw
Message-ID: <13205C286662DE4387D9AF3AC30EF456BCA2D9D7B4@EMBX01-WF.jnpr.net>
References: <2F802BA76C16F746945F3E152126202EB16E7D1F24@EMBX01-WF.jnpr.net>
In-Reply-To: <2F802BA76C16F746945F3E152126202EB16E7D1F24@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pim] RFC 4601bis - erratas
Precedence: list

Hi,

Rishabh, Vero and I have been working on the RFC 4601 erratas with guidence from Stig (and help from an old email from Bill):

> http://www.ietf.org/proceedings/77/slides/pim-0/pim-0_files/v3_document.htm (Stig)
> http://www.rfc-editor.org/errata_search.php?rfc=4601&rec_status=15&presentation=table

http://www.ietf.org/mail-archive/web/pim/current/msg01827.html (Bill)

The following is a report and we would like to have your comments on some of the technical ones.

1. We have re-verified the previously verified/rejected ones.

Except for one minor editorial change (Errata 1175, "is" -> "it") we agree with the existing verified/rejected status.

2. For the reported/held-for-update ones, many of them are editorial (typos, minor grammar, or keywords upper-case vs. lower-case) and are not discussed here.

Some are related to including/correcting page/index references and we are inclined not to adopt the suggestions, other than page/index references provided by existing tools. The main reason is that with electronic versions searching has been extremely easy and much more reliable than hand-managed references.

3. Quite a few are related to implicit "left association" (e.g. Errata 1104). We decided NOT to change the text (e.g. adding parenthesis), but to add the following general statement to section "2.2. Pseudocode Notation":

"Unless otherwise noted, operations specified by statements having multiple (+) and (-) operators should be evaluated from left to right i.e. A (+) B (-) C is the set resulting from union of sets A and B minus elements in set C. "

4. For technical ones, some should be "verified" and some should be "rejected" per our opinion. We're bringing them out to the discussions on the mailing list, as the following.

4a. As Bill stated in his email http://www.ietf.org/mail-archive/web/pim/current/msg01827.html, 1121/1159/1160/1166/1168 are rejected, but we will add some clarifications to 1169/1193.

4b. The following are also rejected:

1113:

Will not try to document vulnerabilities for every option in forged Hello message. For example, Gen ID, other options (current and future) can also have an impact.

We do plan to add a general statement to this effect.

1118:

It's intentional: if expiry timer fires first, so be it and that's the expected behavior. For example, if the Expiry timer has not been refreshed in the last ~180 seconds, then it is acceptable to Prune before PP time expires.

1162/1167:

While an implementation could choose to delay the sending of prunes to avoid traffic disruption, the protocol in general sends immediate prune when RPF changes and does not attempt to address the potential traffic loss that might be prevented.

1194:

Here "may" does not indicate an optional implementation choice. Rather, it just states that Assert messages "might" be generated in response to receiving Assert messages.

5. While reviewing errata 1161, we came upon some question and would like to get your help:

The original question from the errata submitter "When would immediate_olist(*,G) be NULL and forwarding state exist?" is easy to answer: there is a (*,*,RP) downstream Join state.

However, we don't understand why we need to send (*, g) join when the immediate_olist(*, g) is NULL, just because there is a (*, *, RP) join and an assert winner. One assumption is that we need to send (*, g) to the assert winner to pull down traffic, but the assert winner must already have (*, g) or (*, *, rp) state to satisfy CouldAssert() - so it really does not need a (*, g) join from this router to pull down the traffic?

Thanks.
Jeffrey, Rishabh, Vero

Re: [pim] RFC 4601bis - erratas Jeffrey (Zhaohui) Zhang