[pim] Comments on draft-liu-pim-assert-packing
Stig Venaas <stig@venaas.com> Mon, 01 April 2019 18:51 UTC
Return-Path: <stig@venaas.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE131201A1 for <pim@ietfa.amsl.com>; Mon, 1 Apr 2019 11:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com
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 6cVuwsKFoyGa for <pim@ietfa.amsl.com>; Mon, 1 Apr 2019 11:51:40 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F2D12006A for <pim@ietf.org>; Mon, 1 Apr 2019 11:51:39 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id p20so9255970eds.6 for <pim@ietf.org>; Mon, 01 Apr 2019 11:51:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=DsOHpMyLNzJ61WViHk0ufXjqC5w/sdxov10wPsfXz84=; b=RdRx9SPHFoiexBUrIKNIrsnQqepk+2aQDWjxNZ9AqyIUDt1WKsNlzjDT6tU57btBLn jLid0GyoekSJaVOljHnyo4TCsclAA5PZUXjhvprvTRuRRA+AkHCL7katIdrMv+UB45ik O52+7IBmx+W3yzc0IMIQkn/4v0UdK8Odih9a29B0hJh7rbIeUY963tYBdgKe4WJVJwkE IGQFNRKAOU2umDWerI49XRwOB03uGFdU5QM7+rnxcH8FWAPpYm/Ve1v9ZPzbRQh4D/U3 9fgZ5yj0jFb0tUdPflOn4rYH7D7xwg3Xmd/49hNqHAkqbc1io1qGvxIScLw4AoEARlQk gr6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DsOHpMyLNzJ61WViHk0ufXjqC5w/sdxov10wPsfXz84=; b=E3uSjy2lRWw3am4pA0BVZ7xmFjJhnXoecnj9FeMo0lOiblTb/0lufBm9X+VDMMI7+6 HnUrAhT1riW2jR5Z6eqrsIdVU1toEVY2x7dj79VI9jQmEblR9A5YdcR9fSZHomq81A42 oSxHGqZp1I4dqcvHu7wqDtGf9b7NTejbn0ykrZybNyzoKm9rHV5mPkaZMNHu+XeJX2NW 2K4X5SURlITimmJQUL+hUrwcUd9dlwdlZyYiLt9/gqKwkc3MPUbxoIc2gPosoUsV0zVe It3jYjKgvzv2KtufeqkGHQ16OPktHCOwFth7kCdVdUOCPToPIAQJuPtIHt0ElKhKe1he Of7g==
X-Gm-Message-State: APjAAAWKlMzoV3RRNCUeJZvMF8hDVc7ABB4oPwvcJ1kw+LJd0pNB8Bu3 QV/iaHuehe/+SEi1DZR1YH9ZC+8RWVO7cs0N/+d3iVPJxuw=
X-Google-Smtp-Source: APXvYqx8Wi+1n3e7l0m/Fs26ooXMbNUuApfwBWRAXhWwHyQs5RY20yHhR0tmxPBdJPx00z/uQSu1WLZZHruGhyTnvng=
X-Received: by 2002:a17:906:251b:: with SMTP id i27mr37925397ejb.146.1554144697882; Mon, 01 Apr 2019 11:51:37 -0700 (PDT)
MIME-Version: 1.0
From: Stig Venaas <stig@venaas.com>
Date: Mon, 01 Apr 2019 11:51:27 -0700
Message-ID: <CAHANBtLyN9+qshtPoFibV0rtfsesktXzcSUnHzjXBNvS4EeaKA@mail.gmail.com>
To: pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/vF3imfjNTh5XBdCkH95Mqk_VSkI>
Subject: [pim] Comments on draft-liu-pim-assert-packing
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 01 Apr 2019 18:51:42 -0000
Hi I think this is a good idea, but I have some comments. I don't think the use case section is very useful. It doesn't matter whether it is video, financial etc. It might be better to talk about topologies where asserts are likely to happen, but I'm not sure if even that is needed. The capability option announces a single capability type. What should a router that supports both announce? I would suggest to simplify and only have one format. Regarding packing format. I think the format in first part of 4.3 is good. I don't understand why you need the second format with both RP address and source addresses. If you compare with PIM SM RFC, there is no RP address included in asserts even for a (*,G) assert. Regarding the pim message type. I think you should use type sub-type format, see draft-ietf-pim-reserved-bits and draft-ietf-pim-null-register-packing. We need this to not use up the pim type space too quickly. Stig
- [pim] Comments on draft-liu-pim-assert-packing Stig Venaas