Re: [pim] AD Review of draft-ietf-pim-drlb-05

["Heidi Ou (hou)" <[e-mail]>]

Hi, Alia

Thanks for your comments.  I will work on it and we will create a new version after the thanksgiving.

- Heidi

From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
Date: Thursday, November 6, 2014 9:25 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [pim] AD Review of draft-ietf-pim-drlb-05

Hi,

For all publication requests, I do or have done a review of the draft.  I have done that (finally - sorry for the delay!) with draft-ietf-pim-drlb-05.
The draft clearly describes a useful problem to be solved and a reasonable solution.  Thanks to the authors and WG for this work.

Unfortunately, enough of the technical details are under-specified that I would like to see an updated version addressing my concerns and comments before bringing this to IETF Last Call.

Below is my review:

Major Comments:

0) In Sec 6.2, there needs to be very clear specification about what a router's behavior should be that supports this spec.  Specifically,

  a) When a router supports this specification, it creates and advertises a DRLBC Hello Option.
  b) When a router receives a new or modified DRLBGDR from the current PIM DR or when the current PIM DR changes,
      the router checks all flows for which it has been the GDR and if it is no longer the GDR, then it sets its Assert metric for this
      flow to be (PIM_ASSERT_INFINITY - 1), as explained in Sec 6.3.
  c) When a router receives an unchanged DRLBGDR from the current PIM DR, it does nothing.
  d) When a router receives a IGMP/MLD join for a previously unknown flow, the router determines if it is the GDR for the flow.  If so, then the router...
  e) When a router receives an IGMP/MLD join for a flow for which the router has been the GDR AND the DRLBGDR has changed since the last time an IGMP/MLD join for this flow was received, then the router MUST determine if it is still the GDR.  If it is, no new work is needed.  If it is not, then the router sets its Assert metric for this flow to be (PIM_ASSERT_INFINITY -1) and ...   Once this is done, the router should forget that it was previously responsible for the flow.

I'm assuming that a router does not need to store information about IGMP/MLD joins for which the router was not the GDR.


1) In Sec 6.2, there needs to be text describing specifically what a GDR Candidate does when it receives the IGMP/LD join. For example:

"A router supporting this specification processes each DRLBGDR Hello Option received from the current PIM DR. If the router is listed as a GDR
Candidate, then it does the following additional work when an IGMP/MLD join is received. If the router is not listed as a GDR Candidate or no DRLBGDR Hello Option has been received from the current PIM DR, no additional work to process the join is done.

A router which is a GDR Candidate first determines if it is responsible for building forwarding trees on behalf of the host. This is done by using the
masks received in the most recent DRLBGDR Hello Option received from the current PIM DR and the Hash Algorithm that the router advertised in
its DRLBC Hello Option to calculate the appropriate hash value, as described in Sec. 4.3.

If the computed hash matches the router's listing as a GDR Candidate, then the router is responsible for building forwarding trees on behalf of the host.  This means doing...."


2) In Sec 6.3:  Does the following:

 " if a router enables this
   specification on its downstream interface, but it is not a GDR, it
   would adjust its Assert metric to (PIM_ASSERT_INFINITY - 1)."

mean that the router is not the selected GDR for this flow? Is this done when a new DRLBGDR Hello Option is received?  Is this done when a join is refreshed?  As written, it sounds like "not a GDR" is a characteristic of the router -

i.e. not a GDR candidate - instead of not the selected GDR for the particular flow.  The example does clarify it slightly, but specific and clear text is needed.


3) In Sec 6.3, the text says

  "the next PIM Hello option from DR is seen that selects R3 as the

      GDR.  R3 will then build the forwarding tree and send an Assert.

   The process continues until R2 agrees to the selection of R3 as being
   the GDR, and set its own Assert metric to (PIM_ASSERT_INFINITY - 1),
   which will make R3 the Assert winner."

but surely a router would only trigger work only when the DRLBGDR has changed?  As I mentioned  in comment (0), I really think that some description is necessary to explain what the behavior is on receiving an unchanged join or unchanged DRLBGDDR Hello Option.

Are flows which a router has lost the Assert on stored?


Minor Comments:

1) In Sec 4.2, it says "The Hash Masks MUST be configured on the PIM routers that can

   potentially become a PIM DR."  Is this a requirement that implementations must provide a configuration knob for the hash masks?  Why?  Couldn't ones be automatically generated?  Is this a requirement that an operator must configure them - and if so, what guidelines are provided?  What happens if masks aren't configured - for instance on a PIM DR that wasn't expected to become a DR?


2) I see that there is an algorithm ID, but no way to have two algorithms valid at the same time.  That makes it hard to transition. I'm not sure that's a serious concern here.  If it were, then the DRLBC Hello Option could contain multiple Hash Algorithms - showing those supported - and the DRLBGDR Hello Option could contain the Hash Algorithm that the DR has selected (which all the listed GDR Candidates would have to have indicated support for).  This would provide a migration path from one algorithm to another.  If you don't take this suggestion (and assuming there are implementation and this doesn't avoid traffic disruption because the selected GDRs could change), then I'd at least like a "Manageability Considerations" section that discusses this briefly.


3) n Sec 5.2, the formula for calculating the value for the Length should be specified.


4) Remove tentative language, such as "this document suggests".  This is going to be an RFC.  It should sound authoritative!

Nits:

a) Introduction should be the first section.

b) In Sec 4, the sentence "Hash Masks are defined for Source, Group and RP separately, in order

   to handle PIM ASM/SSM." appears twice in consecutive paragraphs.  The repetition should be cleaned up.


c) In Sec 4.2, hashvalue_RP, hashvalue_Group, and hashvalue_SG are used without being defined or tied to the RP Hash Mask, Group Hash Mask, or Source Hash Mask.  It isn't hard to guess the meaning of the first two, but what hashvalue_SG is is not clear from this section.  I see that they are defined in Sec 4.3; at a minimum, please add a forward reference.


Regards,

Alia