Re: WGLC for BFD Multipoint documents (last round)

Greg Mirsky <gregimirsky@gmail.com> Mon, 12 February 2018 02:03 UTC

Return-Path: <gregimirsky@gmail.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 5FCD21205F0 for <rtg-bfd@ietfa.amsl.com>; Sun, 11 Feb 2018 18:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.718
X-Spam-Level:
X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GAoHd3WsCne3 for <rtg-bfd@ietfa.amsl.com>; Sun, 11 Feb 2018 18:03:18 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AB412025C for <rtg-bfd@ietf.org>; Sun, 11 Feb 2018 18:03:17 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id g72so18388758lfg.5 for <rtg-bfd@ietf.org>; Sun, 11 Feb 2018 18:03:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BZVBRfOjLsVlQLmkqW/aF0bW1PohW8QlIZUhIvc45r0=; b=mUyBWbB4QWXeJKnYmDXXlE1QDEF9WUc0PfRZ0/pg2p2Q8SSET4CUMC+EmkVVszMNj6 JD1QJazmJwefsxkSPbQsf0yNS7Pb0v8zSHSgPOUgban+Qz/bypWi4PkjssM3U2bIT3kS h/MTHBUCbvOJfPaZAbCk2ugyzwloO2TfkY1vjjGeDjwXTGOnT3UfnS6NzKUjsrfsZgsM HnDQy6EGUu7FKQCCz7ZxqIFybLzRnceRTz+rTT0ENLYph1hQRPQ4FClM0z9NgEDIi1tP 3sfX+ZMqxw166advGsSQRctQR93VCl/IxVKa+3YJlziLwipqe0MlSab5SH3Fs+iHMW/I hI6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BZVBRfOjLsVlQLmkqW/aF0bW1PohW8QlIZUhIvc45r0=; b=RQz1wefUAFCiMRVlc6Dx6NCJ7mCJhzsLdtaY+vefJcftrZ6g2WW30pqhFv8X57oN/l dA2JU6Z/+vY1OvhOmI28s8lczh2z/4U+esTvtTUW8C3EvlXVekj/yRDuJmnskRs4m+X1 9ynpVzswmfkjuvyLVHUa0kn2qFeidqXPvRZzU5jHxCG/YJnlW/mJ9OB/gxpJSmj7HxMs Czt9F6IALfW2XrghFxkHJ3igVhRvPHByExHrO3fwGhE1OLXhjjTEj6pvRYNjYmkD9U9D ftjQM9cuzvnJ5g1TaOQBU81AviNHdWRhfOPalQjupg23LTVC3ilFUpkDjBsdlh01MOrx QX/A==
X-Gm-Message-State: APf1xPCqUjo54mGG2j3eUnNkgDBTLbhUta/6E7m8DdcP/b12kr76HSZT f95P4ARi+OP8z7sgIVnyAv0t1uQ64ht8298Nl3M=
X-Google-Smtp-Source: AH8x226IjxCBmT/5WPMgPrxGdVIZDiVUtbUTY3cMfgqFDlWSaU9UAXssXRZHh8J5c12rqJewIBsszAAnUtYuVnWmC+0=
X-Received: by 10.25.233.154 with SMTP id j26mr3544451lfk.30.1518400995817; Sun, 11 Feb 2018 18:03:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.83.91 with HTTP; Sun, 11 Feb 2018 18:03:15 -0800 (PST)
In-Reply-To: <A856C686-EE42-44EF-B1A5-67323A778D88@cisco.com>
References: <201802050933130673047@zte.com.cn, > <6A6D7325-7FF0-4269-A0B0-92AFB253963D@cisco.com> <201802081314229933172@zte.com.cn> <A856C686-EE42-44EF-B1A5-67323A778D88@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 11 Feb 2018 18:03:15 -0800
Message-ID: <CA+RyBmXyoy7zihmKPhsUtiwseEBxnB=8pBYcYopyNYRWvskSiA@mail.gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (last round)
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="001a113c580efb7d510564fa4705"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/wP_eEWcLaX_wbJSM_hj5sGOFxa4>
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: Mon, 12 Feb 2018 02:03:22 -0000

Hi Carlos,
thank you for your thorough review and detailed comments. Please find my
responses in-lined tagged GIM>>.

Regards,
Greg

On Thu, Feb 8, 2018 at 7:19 PM, Carlos Pignataro (cpignata) <
cpignata@cisco.com>; wrote:

> 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”?
>
GIM>> Agree, will remove the quotation marks around 3784. Proposed update:
OLD TEXT:
 Session of
   type MultipointTail MUST identify the packet as BFD with the help of
   destination UDP port number "3784" on IP multipoint path.
NEW TEXT:
Session of type MultipointTail MUST identify packet received on an IP
multipoint path
as BFD control packet if the destination UDP port value equals 3784.


>    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)?
>
GIM>> Since the sentence refers to MultipointTail, I conclude this refers
to the destination endpoint. As Reshad agreed to s/use/expect/
here's proposed update to the sentence:
OLD TEXT:
   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]).
NEW TEXT:
   For multipoint LSPs, when IP/UDP encapsulation of BFD control packets
   is used, MultipointTail MUST expect destination UDP port 3784 and
   destination IP address in 127.0.0.0/8 range for IPv4 or
0:0:0:0:0:FFFF:7F00:0/104 range for
   IPv6 ([RFC8029]).


>    Use of other types of encapsulation for multipoint LSP is outside the
>    scope of this document.
>
> CMP: For BFD Control?
>
GIM>> Will add 'of the BFD control message over' and remove 'for' to result:
Use of other types of encapsulation of the BFD control message over
multipoint LSP  is outside the scope of this document.


> 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
>
> *“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 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> <24242e5637af428891c4db731e7765
> ad.jpg>
> 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
>
>
>
> <image001.gif>
>
> <image002.gif>
> E: gregory.mirsky@ztetx.com
> www.zte.com.cn
>
>
>
>
>
>