Re: WGLC for BFD Multipoint documents (last round)

<gregory.mirsky@ztetx.com> Thu, 08 February 2018 05:14 UTC

Return-Path: <gregory.mirsky@ztetx.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B53312D7F1 for <rtg-bfd@ietfa.amsl.com>; Wed, 7 Feb 2018 21:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.216
X-Spam-Level:
X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 iXCSA2CuGqUY for <rtg-bfd@ietfa.amsl.com>; Wed, 7 Feb 2018 21:14:31 -0800 (PST)
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 9C14C1241F5 for <rtg-bfd@ietf.org>; Wed, 7 Feb 2018 21:14:29 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id A57103D0600E5C138A06; Thu, 8 Feb 2018 13:14:27 +0800 (CST)
Received: from mgapp01.zte.com.cn ([10.36.9.142]) by mse01.zte.com.cn with SMTP id w185EMOA090797; Thu, 8 Feb 2018 13:14:22 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Thu, 8 Feb 2018 13:14:22 +0800 (CST)
Date: Thu, 08 Feb 2018 13:14:22 +0800
X-Zmail-TransId: 2af95a7bdcae774-c9bb5
X-Mailer: Zmail v1.0
Message-ID: <201802081314229933172@zte.com.cn>
In-Reply-To: <6A6D7325-7FF0-4269-A0B0-92AFB253963D@cisco.com>
References: 201802050933130673047@zte.com.cn, 6A6D7325-7FF0-4269-A0B0-92AFB253963D@cisco.com
Mime-Version: 1.0
From: gregory.mirsky@ztetx.com
To: rrahman@cisco.com
Cc: rtg-bfd@ietf.org
Subject: Re: WGLC for BFD Multipoint documents (last round)
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse01.zte.com.cn w185EMOA090797
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/X4h8RyJ6B2twjdB71KFJFr7rJVM>
X-Mailman-Approved-At: Thu, 08 Feb 2018 05:51:29 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2018 05:14:34 -0000

Hi Reshad,


thank you for your consideration. I've came across what looks as simple editorial change. Appreciate your comment.


In the second paragraph of section 4.8 Packet consumption on tails the following


  For multipoint LSPs, when IP/UDP encapsulation of BFD control packets

  is used, MultipointTail MUST use destination UDP port "3784" ...

reads akwardly because, I think, of 'MUST use'. I propose simple s/use/look for/ or s/use/expect/. What do you think? Is the text god as-is or minor editing may help?







Regards,


Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division









E: gregory.mirsky@ztetx.com 
www.zte.com.cn






Original Mail



Sender: ReshadRahman(rrahman) <rrahman@cisco.com>
To: gregory mirsky10211915;rtg-bfd@ietf.org <rtg-bfd@ietf.org>
Date: 2018/02/08 11:03
Subject: Re: WGLC for BFD Multipoint documents (last round)




<Sorry for the delay>


Hi Greg,


 


I would go with normative SHOULD. What you proposed below is fine.


 


Regards,


Reshad.


 


 



From: "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>
 Date: Sunday, February 4, 2018 at 8:33 PM
 To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
 Subject: Re: WGLC for BFD Multipoint documents (last round)



 

Hi Reshad,

you've said:

Hi Greg,   While OOB mechanism would improve security, my personal opinion is that we should try to improve security without requiring an OOB mechanism. I think we can add text to the security considerations to address the concerns below, e.g. A tail SHOULD prevent the number of MultipointTail sessions from exceeding the number of expected streams.  The concern expressed in b) cannot be fixed by what I proposed because of multiple streams.  So just preventing the number of MultipointTail sessions from exceeding the number of expected streams should be good enough.   Regards, Reshad.  

If we make it normative SHOULD, i.e. s/should/SHOULD/ in the third recommendation to the implementers:

     The implementation SHOULD have a reasonable upper bound on the

      number of MultipointTail sessions that can be created, with the

      upper bound potentially being computed based on the number of

      multicast streams that the system is expecting.

 

Or keep the lower case as it is consistent with the rest of the section, e.g. 'a MultipointTail session should not be created'?

 

Kind regards,

Greg Mirsky


 


Sr. Standardization Expert
 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division


 






 E: gregory.mirsky@ztetx.com 
 www.zte.com.cn