Re: WGLC for BFD Multipoint documents (ending July 14, 2017)

Greg Mirsky <gregimirsky@gmail.com> Sat, 08 July 2017 01:16 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 B343A12EC28 for <rtg-bfd@ietfa.amsl.com>; Fri, 7 Jul 2017 18:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 0lX8Km7awcyG for <rtg-bfd@ietfa.amsl.com>; Fri, 7 Jul 2017 18:16:55 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 E86931274D2 for <rtg-bfd@ietf.org>; Fri, 7 Jul 2017 18:16:54 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id b40so39789983qtb.2 for <rtg-bfd@ietf.org>; Fri, 07 Jul 2017 18:16:54 -0700 (PDT)
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=NQhj/8jU42QnYq+AKZS5s00gP6VEVQExfqg6umZKmvY=; b=t/chuC5OhZIvIwgtp7QSP2+cUlsTqrq+ZS42+DQo6t+hIXh3ls5EyGwyo92dcxhBU/ 7L9mEx5I4+r3Cc+McuN41kkcAG2rpVEtkL7SOSMtidj7saLcIVjdsy8KV25K+QW9N7hd rKul/bQoRt1IJq3WEZo3c3zO3nAvywnlmLYLfKAMievEWYAvkWbu1ns/GLbBdg6vaMfC 8dce3ziLhCmXggykQuCss2xXWJE0Faw6berL2SExzZwKGlPXfHmGZ+OSXEzTXYK5qwNk o/GGAF/QpK3hg58KGR1HexygOLlfEq+p7O27x2Naa2igb6fsE526dHj0X1y5R7FzOOzm Q1yA==
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=NQhj/8jU42QnYq+AKZS5s00gP6VEVQExfqg6umZKmvY=; b=NnUDYKT97vDyHh/b8mTBLfoXsu4hD0eQ8eYsLbrqqY61Hhso/mgRotg+xNgAempXxZ zfuFBmaWVknT9+ykE35g1vQEg8UubFUELa/Wmx5vV1sT2zhkTPh8jxkpjczKWPMSRhZv zORpZ7n+vzQCSxnUil7DyEl9sQY0QoN3YesF9mPFdPQkhG2guELCTRzjo6FMt3NMsXIf /tYnjqxSnP5oCTOx7o6FrDoPWYmxFUaJpYlGuBXKYbcco9G4bFVGeHXlJJRhGAm7vvBx NRPhTM5jin/CuA4/q3VvraFaZvFj1IITHJ3Fi15gcLn1ImRGeSMhCqT3z9+/71n9eNTm P9YQ==
X-Gm-Message-State: AIVw110JuoRCVIuJNDDEFDMC+bQJCB7DA5RwZ/GW1Jk0Eh4q7s7ol34a CWiAQJPo8b01uqIW9KGIlEedQtYnFw==
X-Received: by 10.237.54.73 with SMTP id e67mr4562996qtb.230.1499476613951; Fri, 07 Jul 2017 18:16:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.227 with HTTP; Fri, 7 Jul 2017 18:16:53 -0700 (PDT)
In-Reply-To: <CA+RyBmXkZ9j5OsDBk76UyXpySWibuzyTVTnXbbepMKmFuMeueA@mail.gmail.com>
References: <20170619193929.GE22146@pfrc.org> <CA+RyBmUfOe-1u7_MVwNt394B181XavLmTg4gA16v-4Mf1XWhGA@mail.gmail.com> <CACi9rdsWYM96UfTD3K3P88nt9M-vT=9A6YOySbQy8aR4YZL5+A@mail.gmail.com> <CA+RyBmXkZ9j5OsDBk76UyXpySWibuzyTVTnXbbepMKmFuMeueA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 7 Jul 2017 18:16:53 -0700
Message-ID: <CA+RyBmV=jnt9=gqFu_O59cmGErLVD94S_h7vdMH2riZUqa354A@mail.gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017)
To: Santosh P K <santosh.pallagatti@gmail.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="001a1149bda0ec77a50553c41a74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Y0leH1-MZadQO8hTjtLzV308SV4>
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: Sat, 08 Jul 2017 01:16:58 -0000

Hi Santosh, et. al,
another note, question on IP/UDP encapsulation of BFD for multipoint
networks. The document says nothing about values that may be used for
Source UDP port number. Even though MultipointHead will not receive BFD
packets from MultipointTail on the UDP port listed, should we recommend to
use numbers from dynamic range, i.e. 49152 to 65535? I think that the
multipoint document should state, as in RFC 5881:

The source port MUST be in the range 49152 through 65535.

What do you think?

Regards,
Greg

On Thu, Jul 6, 2017 at 11:00 AM, Greg Mirsky <gregimirsky@gmail.com>; wrote:

> Hi Santosh,
> many thanks for your thoughtful consideration of my comments. Please find
> my answers and couple more notes in-line and tagged GIM>>.
>
> Regards,
> Greg
>
> On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K <santosh.pallagatti@gmail.com
> > wrote:
>
>> Hello Greg,
>>    Thanks for your comments. Please see my reply inline tagged[ SPK].
>>
>> Thanks
>> Santosh P K
>>
>> On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky <gregimirsky@gmail.com>;
>> wrote:
>>
>>> Dear Authors, WG chairs, et. al,
>>> please kindly consider my comments to the latest version of the draft as
>>> part of WGLC:
>>>
>>>    - Very general
>>>       - I suggest to add note clarifying that all terms that include
>>>       "connectivity" in the document are being used as alternative to
>>>       "continuity", i.e. existence of a path between the sender and the receiver,
>>>       and should not be interpreted as "connectivity verification in terms of
>>>       transport network".
>>>    - Introduction
>>>       - I find that characterization of BFD and unidirectional
>>>       continuity verification as "natural fit" bit of stretching. Perhaps
>>>       "capable of supporting this use case" is acceptable;
>>>
>>> [SPK] Will take care.
>>
> GIM>> Thanks
>
>>
>>>    - Goals
>>>       - the last statement of non-goal seems little unclear. In fact,
>>>       if there's only one tail, the BFD for multipoint network does verify
>>>       connectivity, though unidirectional, between the head and the tail. I think
>>>       that the intention is to stress that p2p bi-directional connectivity
>>>       verification is not supported by this document.
>>>
>>> [SPK] It only says that this document does not support verification of
>> unicast path between head and tail. I can clarify a bit on this. Please let
>> me know if you have a suggestion for this.
>>
> GIM>> I'd suggest to use unicast in place of point-to-point. Using my
> earlier example, in case when there's only one tail multipoint becomes
> point-to-point.
>
>>
>>
>>>
>>>    - Section 4.7
>>>       - the last paragraph notes that the discriminator value MUST NOT
>>>       be changed. Since Your Discriminator MUST be set to 0 this refers to My
>>>       Discriminator only. I think that explicit reference will make the statement
>>>       more clear. Thus suggest s/the discriminator values/the My Discriminator
>>>       value/
>>>
>>> [SPK] Will take care of this.
>>
> GIM>> Thanks.
>
>>
>>>    - Section 4.8
>>>       - I believe that requiring use of IP/UDP encapsulation for BFD in
>>>       multipoint networks over MPSL LSP is too restrictive. I suggest changing
>>>       text as following:
>>>
>>> OLD:
>>>
>>> For multipoint LSP, MultipointTail MUST use destination UDP port "3784" and IP "127.0.0.0/8" range.
>>>
>>>
>>> NEW
>>>
>>> If IP/UDP encapsulation used by MultipointHead for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784" and IP "127.0.0.0/8" range.
>>>
>>> Use of other types of encapsulation for multipoint LSP is outside the scope of this document.
>>>
>>>
>> [SPK] Thanks. I think this make sense for non MPLS tunnels.
>>
> GIM>> Thanks. As I've looked at the text, I've realized that it misses
> IPv6 case. Please consider the following as my new proposed change (not
> sure but I think that quote marks are not required):
> NEW
> If IP/UDP encapsulation used by MultipointHead for multipoint LSP,
> MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port
> 3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 range
> for IPv6.
> Use of other types of encapsulation for multipoint LSP is outside the
> scope of this document.
>
>
>>>    - Section 4.10
>>>       - I cannot say what bfd.DetectMult packet is. It has not been defined in RFC 5880, nor in this document. What is the scenario described in the second paragraph? Is it when MultipointHead reduces Desired Min TX  Interval thus making defect detection more aggressive?
>>>    -
>>>
>>> [SPK] This section talks about how to handle Poll sequence. In case of
>> Multipoint head we cant afford to send POLL and expect all tail to reply
>> with F bit set. Keeping track and building state at headend will be costly.
>>
>>
> GIM>> Perhaps I wasn't clear in my question.  It was to the opening of
> this sentence:
>
>    The MultipointHead MUST send bfd.DetectMult packets with P bit set at
>    the old transmit interval before using the higher value in order to
>    avoid false detection timeouts at the tails.
>
> I couldn't find reference to "bfd.DetectMult packet" in any document related to BFD.
>
>
>
>>>    - Section 7
>>>       - I think it should be plural in the first paragraph, i.e. s/MultipointTail session/MultipointTail sessions/
>>>       - I think that we can add another consideration to improve, strengthen security of BFD for multipoint network by suggesting that MultipointTail sessions created only for known combination of MultipointHead and My Discriminator. Such information MAY be learned from out-of-band and mechanisms are outside the scope of this document.
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <jhaas@pfrc.org>; wrote:
>>>
>>>> Working Group,
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10
>>>> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04
>>>>
>>>>
>>>> The BFD Multipoint documents have been stable for some time.  Prior
>>>> discussion at meetings has suggested we have an implementation for the
>>>> main
>>>> protocol component.  Also per prior discussions, we split the
>>>> active-tail
>>>> component of the original multipoint document to permit implementors to
>>>> not
>>>> have to worry about implementing active-tail procedures if they weren't
>>>> interested in that feature.
>>>>
>>>> We are starting an extended last call on these documents.  The WGLC will
>>>> conclude on July 14.  This provides ample time for list discussion.  If
>>>> necessary, the IETF-99 meeting may provide for opportunities to close
>>>> any
>>>> contentious technical points.  (BFD is not currently scheduled to meet.)
>>>>
>>>> One item I would like to kick off is the document status of the
>>>> active-tail
>>>> mechanism.  At this time, no one has implemented it that I am aware of.
>>>> Discussion with our AD suggests that publishing the document with
>>>> Experimental status may be reasonable to preserve the work that went
>>>> into
>>>> the proposal.
>>>>
>>>> -- Jeff
>>>>
>>>>
>>>
>>
>