Re: WGLC for BFD Multipoint documents (last round)

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Fri, 09 February 2018 03:19 UTC

Return-Path: <cpignata@cisco.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 9F6C0126E3A for <rtg-bfd@ietfa.amsl.com>; Thu, 8 Feb 2018 19:19:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.549
X-Spam-Level:
X-Spam-Status: No, score=-13.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ySb5OMXXS39l for <rtg-bfd@ietfa.amsl.com>; Thu, 8 Feb 2018 19:19:26 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2383126D85 for <rtg-bfd@ietf.org>; Thu, 8 Feb 2018 19:19:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36860; q=dns/txt; s=iport; t=1518146366; x=1519355966; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CkO6khZZmLevEksGPh2A6DRlhZ7BYBh8Gl064THbXco=; b=dHTESAzBqKFkRGEVtIE4n4r3qDG74X/f9B88UOCyfxsvCBICqS9TPXFX CUMCC4BA1LA+k3rYolWAoiVMPiXqoBHVQyM2IxH4GzzxeGi27n0oLT8rG vwXv+etUj6FSVi9kM8dnSok8JRhHWdDuCCXksBUa9cTIxYD7a6q9GzL/d Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAQCuEn1a/4kNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCWXhmcCgKg1uKJI4lgR1ll1WCGAobhSACGoIVVBgBAgEBAQE?= =?us-ascii?q?BAQJrHQuFIwEBAQQjChwiDhACAQYCEQMBAiEBBgMCAgIwFAkIAgQOBYlRZJFjn?= =?us-ascii?q?XSCJ4UBg3uCCgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2EfIIVgVeBaCmDBYMvBIF?= =?us-ascii?q?ECwEBLAkJHoJZMYIUIAWLco4yigcJApV6gh6SIIsTjEwCERkBgTsBHzmBUHAVZ?= =?us-ascii?q?wGCGwmCTByCBQF4ijKBJYEXAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,481,1511827200"; d="scan'208,217";a="343388793"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2018 03:19:25 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w193JPl5025950 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Feb 2018 03:19:25 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 8 Feb 2018 22:19:24 -0500
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Thu, 8 Feb 2018 22:19:24 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>
CC: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)
Thread-Topic: WGLC for BFD Multipoint documents (last round)
Thread-Index: AQHTniFJbGs0pYB83U6MWgKspk/ChqOZ5zYAgABntACAAXI2AA==
Date: Fri, 9 Feb 2018 03:19:24 +0000
Message-ID: <A856C686-EE42-44EF-B1A5-67323A778D88@cisco.com>
References: <201802050933130673047@zte.com.cn,> <6A6D7325-7FF0-4269-A0B0-92AFB253963D@cisco.com> <201802081314229933172@zte.com.cn>
In-Reply-To: <201802081314229933172@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.133]
Content-Type: multipart/alternative; boundary="_000_A856C686EE4244EFB1A567323A778D88ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/JzruUkaSUEHIw_TC4g4oHlwucj4>
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: Fri, 09 Feb 2018 03:19:30 -0000

Hi, Greg,

When looking for this specific sentence, I got a chance to scan through the document a bit.

It seems to me there are still a number of editorials and potentially non-editorials to be fixed.

Looking at S4.8 only:

   BFD packets received on tails for an IP multicast group MUST be
   consumed by tails and MUST NOT be forwarded to receivers.  Session of
   type MultipointTail MUST identify the packet as BFD with the help of
   destination UDP port number "3784" on IP multipoint path.

CMP: There are a number of “the” or “a[n]” articles missing.

CMP: What is “with the help of”? What is "port number "3784" on IP multipoint path”?

   For multipoint LSPs, when IP/UDP encapsulation of BFD control packets
   is used, MultipointTail MUST use destination UDP port "3784" and
   "127.0.0.0/8" range for IPv4 or "0:0:0:0:0:FFFF:7F00:0/104" range for
   IPv6 ([RFC8029]).  Packets identified as BFD packets MUST be consumed
   by MultipointTail and demultiplex as described in Section 4.13.2
.
CMP: The first sentence is very confusing (besides the “MUST use” that you already called out and that I agree).
CMP: For example, is this the source or destination endpoint? Which address is this (i.e., Destination)?

   Use of other types of encapsulation for multipoint LSP is outside the
   scope of this document.

CMP: For BFD Control?

Also, checking the following section:

4.13.1.  Reception of BFD Control Packets

   The following procedure replaces section 6.8.6 of [RFC5880].
…
      If bfd.SessionType is PointToPoint, update the Detection Time as
      described in [RFC5880] section 6.8.4.  Otherwise, update the
      Detection Time as described in Section 4.11 above.

CMP: The actual set of citations is not clear. If this is a replacement to section 6.8.6 of [RFC5880], then why a citation like “[RFC5880] section 6.8.4"? Isn’t it implied that it is RFC 5880? Or conversely, if it is a replacement updating RFC 5880, how does “in Section 4.11 above” work when inserted in RFC 5880? Its ask relative :-)

Thanks!

—
Carlos Pignataro, carlos@cisco.com<mailto:carlos@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Feb 8, 2018, at 12:14 AM, gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com> wrote:


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


<9ae3e214c17d49ed935d87c674ba3ee2.jpg>  <24242e5637af428891c4db731e7765ad.jpg>
E: gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>
Original Mail
Sender: ReshadRahman(rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>>
To: gregory mirsky10211915;rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> <rtg-bfd@ietf.org<mailto: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<mailto:gregory.mirsky@ztetx.com>" <gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com>>
Date: Sunday, February 4, 2018 at 8:33 PM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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


<image001.gif>

<image002.gif>
E: gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>