Subject: Rtgdir telechat review of draft-ietf-pim-source-discovery-bsr-11

From: Min Ye <[email-masked]>
Date: Tue, 30 Jan 2018 17:48:05 -0800

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.

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.

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"

Editorial:

First paragraph first sentence: add reference to PIM-SM

Second paragraph fifth sentence: add reference to SSM

Last paragraph

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

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

Dimitri

---

From: Stig Venaas <[email-masked]>
Date: Wed, 31 Jan 2018 10:06:30 -0800

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.

> what now defines a PIM domain: the PFM flooding boundary or the PIM execution

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.

> 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.

>    Quantify "small amount of time"

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

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

Fixed.

> Second paragraph fifth sentence: add reference to SSM

Fixed.

> constants from configurable parameters. Cf.RFC 2328 for a good example.

I've done this.

> 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