Re: [pim] pim Digest, Vol 180, Issue 1

Liuyisong <liuyisong@huawei.com> Tue, 02 April 2019 07:41 UTC

Return-Path: <liuyisong@huawei.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 CE6F51201DB for <pim@ietfa.amsl.com>; Tue, 2 Apr 2019 00:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 V4Hs1uL_7HPW for <pim@ietfa.amsl.com>; Tue, 2 Apr 2019 00:41:12 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACC8120089 for <pim@ietf.org>; Tue, 2 Apr 2019 00:41:12 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [10.201.108.34]) by Forcepoint Email with ESMTP id 5DE97A507D0147D001AF for <pim@ietf.org>; Tue, 2 Apr 2019 08:41:10 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 2 Apr 2019 08:41:09 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Tue, 2 Apr 2019 15:41:00 +0800
From: Liuyisong <liuyisong@huawei.com>
To: Stig Venaas <stig@venaas.com>, "pim@ietf.org" <pim@ietf.org>
CC: Michael McBride <Michael.McBride@huawei.com>, Yangang <yangang@huawei.com>, Zhuangshunwan <zhuangshunwan@huawei.com>
Thread-Topic: pim Digest, Vol 180, Issue 1
Thread-Index: AQHU6L10tYHvR+Cr6EOtRd5gDT3an6YodGKQ
Date: Tue, 02 Apr 2019 07:41:00 +0000
Message-ID: <D55792544C0AAD429ADA4746FE3504E08D79FB85@NKGEML515-MBX.china.huawei.com>
References: <mailman.153.1554145232.9163.pim@ietf.org>
In-Reply-To: <mailman.153.1554145232.9163.pim@ietf.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.172.168]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/8yqh_32pqf4dxBXXsBZjtoGzYHc>
Subject: Re: [pim] pim Digest, Vol 180, Issue 1
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: Tue, 02 Apr 2019 07:41:15 -0000

Hi Stig
      Thank you for your comments. Please see my reply below.
Thanks
Yisong

Date: Mon, 1 Apr 2019 11:51:27 -0700
From: Stig Venaas <stig@venaas.com>
To: pim@ietf.org
Subject: [pim] Comments on draft-liu-pim-assert-packing
Message-ID:
	<CAHANBtLyN9+qshtPoFibV0rtfsesktXzcSUnHzjXBNvS4EeaKA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

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.
>>>Liuyisong: This section is to illustrate that assert is still widely used in the network environment of multicast applications. We will also consider the impact of topology and add related descriptions in this section.

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.
>>>Liuyisong: We want to provide multiple choices for implementors.  Because no one of the options is perfect.  A Implementor can choose one option depending on its requirements.

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.
>>>Liuyisong: Because a (*,G) assert actually depends on the route to the RP, and the actual number of RPs in the network deployment is relatively small, so we want to further aggregate the assert records of the same RP. 

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.
>>>Liuyisong: We use a new hello option to negotiate the assert packing capability and will consider the type sub-type format for the packed assert message.

Stig