Subject: Re: [pim] [Technical Errata Reported] RFC3618 (5356)

From: Alvaro Retana <[email-masked]>
Date: Fri, 11 May 2018 11:52:59 -0400

[Adding the pim WG.]

Hi!

I took at look at the document, and [SA-Hold-Down-Period] is not defined
anywhere.  Adding a definition or changing a normative piece of the text is
not something we should be doing using the Errata process for (minor errors
are expected to be corrected that way).  I am then inclined to Reject this
report.

However, and after taking a quick look at the document….
The [HoldTime-Period] is the only hold-related timer defined in the
document.  It makes sense to me for [SG-State-Period] to be at least
the SA-Advertisement-Period + the Peer Hold Timer.  Does that make sense to
anyone else?  If so, then maybe the editorial error was in writing
  [SA-Hold-Down-Period] instead of [HoldTime-Period].

Thanks!

Alvaro.

On May 10, 2018 at 4:15:31 PM, RFC Errata System ([email-masked])
wrote:

The following errata report has been submitted for RFC3618,
"Multicast Source Discovery Protocol (MSDP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5356

--------------------------------------
Type: Technical
Reported by: Frank Hua Li <[email-masked]>

Section: 5.3

Original Text
-------------
5.3. SA Cache Timeout (SA-State Timer)

Each entry in an SA Cache has an associated SA-State Timer. A
(S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
received by an MSDP peer. The timer is reset to [SG-State-Period] if
another (S,G)-SA message is received before the (S,G)-SA-State Timer
expires. [SG-State-Period] MUST NOT be less than [SA-Advertisement-
Period] + [SA-Hold-Down-Period].

Corrected Text
--------------
5.3. SA Cache Timeout (SA-State Timer)

Each entry in an SA Cache has an associated SA-State Timer. A
(S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
received by an MSDP peer. The timer is reset to [SG-State-Period] if
another (S,G)-SA message is received before the (S,G)-SA-State Timer
expires. [SG-State-Period] MUST NOT be less than [SA-Advertisement-
Period].

Or define the [SA-Hold-Down-Period] refers to.

Notes
-----
There is no definition of [SA-Hold-Down-Period] timer in the document. We
should either remove the reference of [SA-Hold-Down-Period] from 5.3 or
clearly define what [SA-Hold-Down-Period] refers to. If not, this will
cause confusion for implementation.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC3618 (draft-ietf-msdp-spec-20)
--------------------------------------
Title : Multicast Source Discovery Protocol (MSDP)
Publication Date : October 2003
Author(s) : B. Fenner, Ed., D. Meyer, Ed.
Category : EXPERIMENTAL
Source : Multicast Source Discovery Protocol
Area : Routing
Stream : IETF
Verifying Party : IESG

---

From: Frank Li <[email-masked]>
Date: Fri, 11 May 2018 10:42:22 -0600

Thank you Alvaro for reviewing this quick. Here is my two cents:

RFC 3618 states that  "[SG-State-Period] MUST NOT be less than
[SA-Advertisement-Period] + [SA-Hold-Down-Period]". This implies that one
purpose for the [SA-Hold-Down-Period] is to ensure that the SA entry can be
refreshed by the SA advertisement. RFC 3618 also states "[HoldTime-Period]
MUST be at least three seconds.  The recommended value for [HoldTime-Period]
is 75 seconds." In this regards, the HoldTime-Period will be able to serve
the purpose for [SG-State-Period].

Another possible purpose of the [SA-Hold-Down-Period] is to "extend" the
life of the local SA entry. With my observation, if I am right, Cxxxx Ixx
implemented 6 minutes (300 seconds) for the [SA-Hold-Down-Period], and
Cxxxx Nxxxx implemented 150 seconds for the [SA-Hold-Down-Period].

The bottom line is that [SA-Hold-Down-Period] shouldn't be zero. In
reality, it may be beneficial to allow missing one SA advertisement and
still keep the SA entry live. Change the [SA-Hold-Down-Period] to be the
same as [HoldTime-Period] could serve the purpose but may limit the
flexibility of the MSDP implementation.

I think this Errata could either be rejected. Or add a statement such
as: *[SA-Hold-Down-Period]
SHOULD be a non zero value. Or [SA-Hold-Down-Period] should be at least 3
seconds *(3 seconds is more of a arbitrary number). Personally, I prefer
the later statement so we can have an expected minimum value in
implementation. If we reject the Errata, I suggest to add the statement in
future release.

Thanks.

-Frank Hua Li

Frank Li

Solutions Architect & CEO
CCIE Security #14683
CCIE Routing & Switching #14683
Standard IT Solutions Corporation
Tel: (306) 370-2075
Fax: (306) 954-3488
Email: [email-masked]

On Fri, May 11, 2018 at 9:52 AM, Alvaro Retana <[email-masked]>
wrote:

> On May 10, 2018 at 4:15:31 PM, RFC Errata System (
> [email-masked]) wrote:
>

---

From: Stig Venaas <[email-masked]>
Date: Tue, 15 May 2018 12:03:47 -0700

Hi

The hold down has basically been replaced with the Peer Hold Timer in
5.4. But I would have to look more closely at it to figure out what
makes sense for the protocol. It might be that should just delete the
hold down part.

Stig

On Fri, May 11, 2018 at 9:42 AM, Frank Li <[email-masked]> wrote:
> implemented 6 minutes (300 seconds) for the [SA-Hold-Down-Period], and Cxxxx
> Nxxxx implemented 150 seconds for the [SA-Hold-Down-Period].
>
> The bottom line is that [SA-Hold-Down-Period] shouldn't be zero. In reality,
> it may be beneficial to allow missing one SA advertisement and still keep
> the SA entry live. Change the [SA-Hold-Down-Period] to be the same as
> [HoldTime-Period] could serve the purpose but may limit the flexibility of
> the MSDP implementation.
>
> I think this Errata could either be rejected. Or add a statement such as:
> [SA-Hold-Down-Period] SHOULD be a non zero value. Or [SA-Hold-Down-Period]
> should be at least 3 seconds (3 seconds is more of a arbitrary number).
> Personally, I prefer the later statement so we can have an expected minimum
> value in implementation. If we reject the Errata, I suggest to add the
> statement in future release.
>
>
> Thanks.
>
> -Frank Hua Li
>
> Frank Li
>
>> However, and after taking a quick look at the document…. The
>> [HoldTime-Period] is the only hold-related timer defined in the document.
>> It makes sense to me for [SG-State-Period] to be at least the
>> SA-Advertisement-Period + the Peer Hold Timer.  Does that make sense to
>> On May 10, 2018 at 4:15:31 PM, RFC Errata System
>> ([email-masked]) wrote:
>>
>> clearly define what [SA-Hold-Down-Period] refers to. If not, this will cause
>> confusion for implementation.
>>
>> Instructions:
>> -------------
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 16 May 2018 13:27:46 -0700

Hi

While as I wrote yesterday the hold down was replaced by a peer hold
timer, they are per my understanding very different. The hold down
basically meant that you did not forward an SA until the hold down
expired. See draft-ietf-msdp-spec-12. Because of this, it had to be
taken into account for the SA expiry timer. There is nothing like this
in the RFC.

Hence, I believe the errata is correct. "+ [SA-Hold-Down-Period]"
should be removed, so that it says:

 [SG-State-Period] MUST NOT be less than [SA-Advertisement-Period]

Stig

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 18 May 2018 12:33:59 -0700

Hi!

As I said before, changing Normative text (removing [SA-Hold-Down-Period])
is not something we should be doing through this process.  Instead,
discussion and an eventual revision of the document would contain the
change.

I am then going to Reject this report, but will include a pointer to this
discussion so that if/when the document is revised there is a record.

Thanks!

Alvaro.

On May 16, 2018 at 4:27:47 PM, Stig Venaas ([email-masked]) wrote:

Hi

Stig

>> implemented 6 minutes (300 seconds) for the [SA-Hold-Down-Period], and
Cxxxx
>> The bottom line is that [SA-Hold-Down-Period] shouldn't be zero. In
reality,
>>> "Multicast Source Discovery Protocol (MSDP)".
cause

---

From: Frank Li <[email-masked]>
Date: Fri, 18 May 2018 14:02:43 -0600

Thank you Stig for referring the "draft-ietf-msdp-spec-12" which contains
the history of the "SA-Hold-Down Timer".

Quote from "draft-ietf-msdp-spec-12":
8.4. SA-Hold-Down Timer *[Note: This section is removed from RFC3618
entirely]*
   When an SA message is received which creates (S,G) state, the
   (S,G)-SA message will be forwarded if the peer-RPF check succeeds. If
   the peer-RPF check succeeds and the (S,G)-SA message is not already
   in the SA cache, then the (S,G)-SA-Hold-Down timer is set to [SA-
   Hold-Down-Period] seconds. When an (S,G)-SA message is received and
   an (S,G) entry already exists, the message is forwarded only if the
   (S,G)-SA-Hold-Down timer is not running. *[SA-Hold-Down-Period] SHOULD*
*   be set to 30 seconds.*
Unquote.

When the draft is re-versioned as experimental RFC3618, it seems the above
statement of the "SA-Hold-Down Timer " was removed. As such, I agree with
Stig, the "[SA-Hold-Down-Period]" should be removed from section 8.3 of the
RFC3618. In my opinion, this isn't a change of narrative, require
[SA-Hold-Down-Period]
or not is a change of implementation requirement.

If the intention of RFC3618 is NOT to require the implementation of
"[SA-Hold-Down-Period]",
then this is a valid errata. If the intention of RFC3618 is to require the
implementation of "[SA-Hold-Down-Period]", we may want to add back the
above statement, or something similar, as in "draft-ietf-msdp-spec-12".

8.3 <https://tools.ietf.org/html/draft-ietf-msdp-spec-12#section-8.3>.
SA Cache Timeout (SA-State Timer)

   Each entry in an SA Cache has an associated SA-State Timer.  A
   (S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
   received by a MSDP peer. The timer is reset to [SA-State-Period] if
   another (S,G)-SA message is received before the (S,G)-SA-State Timer
   expires. [SA-State-Period] MUST NOT be less than [SA-Advertisement-
   Period] *+ [SA-Hold-Down-Period].*

Thank you for included myself in the discussion.

Frank Li