Re: WGLC for BFD Multipoint documents (last round)

"Reshad Rahman (rrahman)" <> Thu, 08 February 2018 03:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8277E1289B0 for <>; Wed, 7 Feb 2018 19:03:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mIVjqijbp28S for <>; Wed, 7 Feb 2018 19:03:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 997A312773A for <>; Wed, 7 Feb 2018 19:03:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31600; q=dns/txt; s=iport; t=1518058994; x=1519268594; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ulL+EErR+Awqc6A2QJHeMiQtdS59OPmIW9WTyOX/hWk=; b=dA5mDcALhIBHVNDMDNrWtm8ZL39rUDGMeaF71fVl1ZvF9sjN94rhzjmN iwor5tiXYiCwewxarGFCJnFJvw+nV4Dg6l0iwxBMLjII8bbfKEaJ5ytVw q+woJbln/EUvcKkatJd0xDJlAj5ArS6OWMvG3I1Zge/hniWqlxIJPCpF/ 4=;
X-Files: image001.gif, image002.gif : 6017, 2066
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.46,476,1511827200"; d="gif'147?scan'147,208,217,147";a="353160377"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 03:03:13 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w1833DxI007509 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2018 03:03:13 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 7 Feb 2018 21:03:12 -0600
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 7 Feb 2018 21:03:12 -0600
From: "Reshad Rahman (rrahman)" <>
To: "" <>, "" <>
Subject: Re: WGLC for BFD Multipoint documents (last round)
Thread-Topic: WGLC for BFD Multipoint documents (last round)
Thread-Index: AQHTniFJQKkp4UZhy0e3Kn8Lrj3T1qOZ5zYA
Date: Thu, 8 Feb 2018 03:03:12 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/related; boundary="_005_6A6D73257FF04269A0B092AFB253963Dciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Feb 2018 03:03:16 -0000

<Sorry for the delay>
Hi Greg,

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


From: ""; <>;
Date: Sunday, February 4, 2018 at 8:33 PM
To: "Reshad Rahman (rrahman)" <>;, ""; <>;
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.



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