Re: [RTG-DIR] Rtgdir telechat review of draft-ietf-pim-source-discovery-bsr-11

Stig Venaas <stig@venaas.com> Wed, 31 January 2018 18:06 UTC

MIME-Version: 1.0
In-Reply-To: <151736328522.7871.1037222625991438704@ietfa.amsl.com>
References: <151736328522.7871.1037222625991438704@ietfa.amsl.com>
From: Stig Venaas <stig@venaas.com>
Date: Wed, 31 Jan 2018 10:06:30 -0800
Message-ID: <CAHANBtLp86AXmyxA4FY-D=HYvV0mSKd76WL+V2p2-0NruscGeQ@mail.gmail.com>
To: Min Ye <amy.yemin@huawei.com>
Cc: rtg-dir@ietf.org, draft-ietf-pim-source-discovery-bsr.all@ietf.org, ietf@ietf.org, pim@ietf.org, dimitri.papadimitriou@nokia-bell-labs.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/IFSjk9LyV4f2J_ilgJ0Zc5SjzLM>
Subject: Re: [RTG-DIR] Rtgdir telechat review of draft-ietf-pim-source-discovery-bsr-11
Precedence: list

Hi

I've now posted version 12 that addresses some of these points, please
see comments inline. I hope that version 12 sufficiently addresses the
review comments, and can be approved.

On Tue, Jan 30, 2018 at 5:48 PM, Min Ye <amy.yemin@huawei.com> wrote:
> Reviewer: Papadimitriou Dimitri
> Review result: Has Nits
>
> Couldn't find the template for experiment drafts, but I think this kind of
> documents deserve its specific template
>
> Summary:
>
> Points to be clarified are related to
>
> 1.the flooding boundary. The document refers to PIM domain defined in RFC 4601
>
> " A domain in this context is a contiguous set of routers that all implement
> PIM and are
>    configured to operate within a common boundary."
>
> And states " PFM messages are generally forwarded hop by hop to all PIM
> routers."
>
> what now defines a PIM domain: the PFM flooding boundary or the PIM execution
> domain.

The text you refer to is in the context of BSR where the domain is
within the boundaries defined for BSR. Similarly for PFM it will be
within the PFM boundaries.

> 2. Modified TLV (statement " Some TLVs may be omitted or modified in the
> forwarded message." - example a boundary router changes the Src Address in the
> GSH TLV to its own address - is that allowed/expected ? actually the document
> doesn't explain or justify the need to "modify" TLV in forwarded messages.

Yes, we want to allow this. We do not want this for the GSH TLV, but
new TLVs could be defined where this is needed. E.g., if we defined a
TLV for source hop-count, or message hop-count, we might want the
value to be increased by 1 each time a message is forwarded.

> 3. Section 4.2 states
>
>    "In order to meet the timing requirements, sending of the message may
>    have to be delayed a small amount of time."
>
>    Quantify "small amount of time"

I agree this is not very precise, but it is quantified in the timing
requirements we are referring to.

> Editorial:
>
> First paragraph first sentence: add reference to PIM-SM

Fixed.

> Second paragraph fifth sentence: add reference to SSM

Fixed.

> Last paragraph
>
> o) Refers to "parameters" please differentiate so-called architectural
> constants from configurable parameters. Cf.RFC 2328 for a good example.

I've done this.

> o) Suggest to write last paragraph as numbered points to facilitate their
> clearing as more experience from the field is being obtained.

I thought about doing this, but I feel the points are fairly
interconnected. It is all about scale and I do not see how we could
say how one point is cleared and another is not. But hopefully at some
point we have more experience and we can revise this in a bis
document.

Thanks for review,
Stig

> Dimitri
>

[RTG-DIR] Rtgdir telechat review of draft-ietf-pi… Min Ye
Re: [RTG-DIR] Rtgdir telechat review of draft-iet… Stig Venaas