[pim] comments on draft-ietf-pim-null-register-packing-09

zhang.zheng@zte.com.cn Mon, 24 May 2021 02:52 UTC

Return-Path: <zhang.zheng@zte.com.cn>
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 316B83A12EC for <pim@ietfa.amsl.com>; Sun, 23 May 2021 19:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.187
X-Spam-Level:
X-Spam-Status: No, score=-4.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, UNPARSEABLE_RELAY=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 2UFaIFgW3aYY for <pim@ietfa.amsl.com>; Sun, 23 May 2021 19:52:16 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 2C7F53A12E2 for <pim@ietf.org>; Sun, 23 May 2021 19:52:15 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 9FD2EF709F5670ECA7B3; Mon, 24 May 2021 10:52:11 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 14O2pkJD070377; Mon, 24 May 2021 10:51:46 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Mon, 24 May 2021 10:51:46 +0800 (CST)
Date: Mon, 24 May 2021 10:51:46 +0800
X-Zmail-TransId: 2afd60ab14c27f847eaa
X-Mailer: Zmail v1.0
Message-ID: <202105241051460723178@zte.com.cn>
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: vkamath@vmware.com, ramaksun@cisco.com, rbanthia@apstra.com, ananygop@cisco.com
Cc: pim@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 14O2pkJD070377
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/1FZZWVtlzsJDMqGNKnIbWzSaZnA>
Subject: [pim] comments on draft-ietf-pim-null-register-packing-09
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, 24 May 2021 02:52:21 -0000

Hi authors, 


Thank you for the 09 version update! The version makes more clear about the function. 


I have some comments for the new 09 version:


1. In the combinations 1 in section 5, there is 


"As specified in [[RFC7761]], the DR sends PIM Null-Register

          messages towards the RP when a new source is detected." 

I noticed that the "Register messages" has been changed to "Null-Register messages". The change seems like to be confusion. 

Because "when a new source is detected", the DR sends data-register to the RP other than null-register. 

After the RP builds the tree to the DR, RP can set the P-bit in the register-stop message sent to the DR, that is the RP can set the P-bit when it starts to send register-stop to the DR. 

So IMO in this sentence, the "PIM Null-Register" may go back to "PIM register".

2. In case the RP enables the packed capability and works well, but the network manager disables the packed capability in the RP. During the switch, there may be two ways:

One is that the RP can still parse the packed null-register messages, but it sends the register-stop message without P-bit set. Then the DR sends the unpacked null-register to the RP. 

The other is that the RP stops to parse the packed null-register messages right now, the DR may not receive the register-stop message with P-bit set/clear from the RP, then the DR may send the new un-packed register message after the timer expired and then receives the register-stop message with P-bit clear from the RP. 

I am not sure which one is prefer in this draft. IMO it may be better to add some description about the switch issue. 

Best regards,

Sandy