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

Alia Atlas <akatlas@gmail.com> Thu, 06 November 2014 17:26 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873201A88BD for <pim@ietfa.amsl.com>; Thu, 6 Nov 2014 09:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLN0nAlvFe2R for <pim@ietfa.amsl.com>; Thu, 6 Nov 2014 09:25:58 -0800 (PST)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931541A88AE for <pim@ietf.org>; Thu, 6 Nov 2014 09:25:58 -0800 (PST)
Received: by mail-yk0-f181.google.com with SMTP id 19so1483385ykq.26 for <pim@ietf.org>; Thu, 06 Nov 2014 09:25:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WLVkj7T9NQX4kgd9Qi5ZZWEKbW/PEJOWufvTWDCzAwU=; b=FSDAFA73fqsxCXiVfAoJpyS+UuOXwqMzts9RSKhcAtjUrB1vt7Tf70PgYreeGo58bK ir2S2Bc44erMyD6XrEgJwQIP/m+A/uYxXm/B/B5ez8xuXLt0LRbkZYMk+S4muF9Bfg2q +XmfAp/Mp27dCmlmFtl0++rn52TKSxfnlpkbgOwP6AeVjcEKUo1Tb7yp2nk+xVaoLNYk I/ksFY/9jNuDlRz92oZHiysDrhIuFlPW33n4M6tWkUvk/cmOjYtFYYi8M8u9mB1Wd2Kd 6wG9Pbjk9aztvFs4Sox1VOfcIN9qcMo9fw+ZhFMHnEvL1O/38Vv9tZcPr6jwazKrlAtA fCHw==
MIME-Version: 1.0
X-Received: by 10.236.109.7 with SMTP id r7mr5381744yhg.107.1415294757706; Thu, 06 Nov 2014 09:25:57 -0800 (PST)
Received: by 10.170.172.130 with HTTP; Thu, 6 Nov 2014 09:25:57 -0800 (PST)
Date: Thu, 06 Nov 2014 12:25:57 -0500
Message-ID: <CAG4d1rewMKVdo-xVWHv+n-V_EULYAK+sS69bCxBUGwbFg=xFUA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: draft-ietf-pim-drlb@tools.ietf.org, pim@ietf.org
Content-Type: multipart/alternative; boundary="001a11c2c59649235b050733fdb7"
Archived-At: http://mailarchive.ietf.org/arch/msg/pim/K61q4--5ZBb9RTMkeud-5MnmuOw
Subject: [pim] AD Review of draft-ietf-pim-drlb-05
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Nov 2014 17:26:01 -0000

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