Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2mp-bfd-04

"Andrew G. Malis" <agmalis@gmail.com> Mon, 19 November 2018 16:23 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A391286E7; Mon, 19 Nov 2018 08:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dXGJe-KGBSJ1; Mon, 19 Nov 2018 08:23:10 -0800 (PST)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 2C2B9130DDF; Mon, 19 Nov 2018 08:23:10 -0800 (PST)
Received: by mail-qk1-x72a.google.com with SMTP id 131so49476657qkd.4; Mon, 19 Nov 2018 08:23:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dO2jqpYR5IrFPE5MaynHezStLkQq4UNkHDC31EvX0jQ=; b=QRt2qUWDzc2XD9kF3JpVEmy908D8ELR2yUt0kTHFeihJ+U0qEnEjR6L77DthYjVqFF lHQjV6qPR/c8kNCq6upp3mQlU/uvKgyYeotkg8aX+Q6RwmyZvuiWDvzjQ6DgjUo6UiA0 uHSKMmcvOMCnzVAY6ECKU5xsmAv/pSONDdJwUqm+aN5dSXLONyxHERscSNL7bOn8x1Rf Vdb0pt83b3SijD8yos+7I59CMfWLM4Rk1y3KRSACXUu2vVIkPT/OyiPXfXeNNUwNh+Pr /hpdzJG8TYu5R7PpMmUTUnMc+X3ElHQnMaiRjuBiG8HlpEADM8WwQycSfw3XFhpU3iAs TAXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dO2jqpYR5IrFPE5MaynHezStLkQq4UNkHDC31EvX0jQ=; b=tvye/kZQkTKh6nnix70CHZgUuBQBMkRdVEGNnhkDzeFtQcegm5sFtFLqdzKMuGxStx rNBjH6H7Mvu7m8cG8I+PjEzXvS0JSG7GHJtKzkLY2Ox0Xygk5giR/PnNsRyYxvzI8vyu 6u4lPoFKrC3s73ruGVjT8A96GI4DeURHVOiacbdILfEfWDgJ4EDdwcFpCS4lKaZopJFa hcDaS2ZjkAuAHcUbzeN/eb6ZGEWVP1IIllpbleM2pJsFFOsn3TaokrcsmVGzEU225Jrj QkMzEUUtKT7L15nr3SrmH3yYBEUx2kmPru6t/SqaXK0ynRlIT+eK3uv2eWwG5vWXimvx e/bA==
X-Gm-Message-State: AGRZ1gKJRjwKFhY4oyuVpfgf2bOc00Lq6EBl7vs7EZecq4hPDB6X7W1p GlV0mbQ51S1+gXFcIJy6rP7pIDv1p9lQwcZmvp/bNldi
X-Google-Smtp-Source: AJdET5eVAWnoRNvE/DAl5Tf4y7sjT5lx9m2EQrxrPogYmmHk59zMwl+3qsrcCRYmgv1DyGFtybmLXBPLJalzQEqqDoE=
X-Received: by 2002:ac8:2eb8:: with SMTP id h53mr21368830qta.18.1542644588989; Mon, 19 Nov 2018 08:23:08 -0800 (PST)
MIME-Version: 1.0
References: <CAA=duU2kQWCg5CfidXAw8M+1VivgY=C2cehCcEVUQ0D_1yYxSg@mail.gmail.com> <CA+RyBmVLDKOsaJhDzdDKmF9WEk1Hwg7-LN25onVdK3fXk7bHSw@mail.gmail.com> <CA+RyBmXeQp+jFji-s5SsMDZTiwgNZ2Zfkcc0NHhwvnQ7jegdow@mail.gmail.com> <CAA=duU3eaXNPhSddxDxzrazL8NSwsVpR2TtkxLqH3YODBf=3Yw@mail.gmail.com> <CA+RyBmUv=Vni=U3skpk-KujTGVdX9Gz88_+G3tj+jtco+qYijw@mail.gmail.com>
In-Reply-To: <CA+RyBmUv=Vni=U3skpk-KujTGVdX9Gz88_+G3tj+jtco+qYijw@mail.gmail.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 19 Nov 2018 11:22:57 -0500
Message-ID: <CAA=duU0tD-FU84AXLTZwjHEfUwcV2UCZhOOWGJbfU40jXYujpQ@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: mpls-chairs <mpls-chairs@ietf.org>, draft-mirsky-mpls-p2mp-bfd@ietf.org, mpls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bdd156057b06ee2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/0ZLqdhCRUUPYThOiZuuCYRBqSEk>
Subject: Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2mp-bfd-04
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 16:23:14 -0000

Greg,

It's looking much better, thanks.

In your new text, I noticed some missing words at the end of section 3. In
the following, I've bolded and italicized the missing words.

   If *the* BFD control packet *is* encapsulated in
   IP/UDP, *then* the source IP address MUST be used to demultiplex the
   received BFD control packet as described in Section 3.1.  *The* non-IP
   encapsulation case *is* described in Section 3.2.

Just make those changes, and then upload it for the adoption poll.

Thanks again,
Andy



On Sun, Nov 18, 2018 at 5:13 PM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Andy,
> please find my notes and answers in-line tagged GIM2>>. All updates can be
> reviewed in the attached diff and the working version of the draft.
>
> Regards,
> Greg
>
> On Wed, Oct 31, 2018 at 6:41 AM Andrew G. Malis <agmalis@gmail.com> wrote:
>
>> Greg,
>>
>> Thanks for checking.
>>
>> You didn't really address my comment: "I would have expected to see at
>> least a reference to RFC 4687, "Operations and Management (OAM)
>> Requirements for Point-to-Multipoint MPLS Networks", and some text on how
>> this draft addresses the requirements in that draft.".
>>
> GIM>> This is not the specification for p2mp BFD. Issues of scaling and
> performance of p2mp BFD discussed in detail in BFD for Multipoint Neworks
> for use case of tail-only monitoring the unidirectional path, and BFD for
> Multipoint Networks with Active Tail, for scenarios when the head uses
> multipoint Poll sequence optionally in combination with unicasted Poll to
> the particular tail to be aware of the state of the unidirectional path of
> the multicast tree to tha tail. For example, the Security Considerations in
> draft-ietf-bfd-multipoint suggest that:
>       If redundant streams are expected for a given multicast stream,
>       then the implementations should not create more MultipointTail
>       sessions than the number of streams.  Additionally, when the
>       number of MultipointTail sessions exceeds the number of expected
>       streams, then the implementation should generate an alarm to users
>       to indicate the anomaly.
>
>       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.
>
> draft-ietf-bfd-multipoint-active-tail additionally notes that:
> implementations that create MultpointClient sessions
>    dynamically upon receipt of BFD Control packet from a tail MUST
>    implement protective measures to prevent an infinite number of
>    MultipointClient sessions being created.  Below are listed some
>    points to be considered in such implementations.
>
>       When the number of MultipointClient sessions exceeds the number of
>       expected tails, then the implementation should generate an alarm
>       to users to indicate the anomaly.
>
>       The implementation should have a reasonable upper bound on the
>       number of MultipointClient sessions that can be created, with the
>       upper bound potentially being computed based on the number of
>       multicast streams that the system is expecting.
>
> In addition to these considerations listed in the base specifications for
> p2mp BFD, I've added the following text:
>     Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in
>    section 4.1 [RFC4687] to avoid congestion in the control plane or the
>    data plane caused by the rate of generating BFD control packets.  An
>    operator SHOULD consider the amount of extra traffic generated by
>    p2mp BFD when selecting the interval at which the MultipointHead will
>    transmit BFD control packets.  Also, the operator MAY consider the
>    size of the packet the MultipointHead transmits periodically as using
>    IP/UDP encapsulation adds up to 28 octets, which is more than 50% of
>    BFD control packet length, comparing to G-ACh encapsulation.
>
>
>> You added a reference in the security section, but nothing about how your
>> draft addresses the 4687 requirements.
>>
>> Also, you didn't really address my next comment: "I also expected more
>> text on the relationship between this draft and RFC 6425, "Detecting
>> Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping"',
>> and more of an explanation of why the keyword MAY is used in sections 4.1
>> and 4.2 - what are the implications of following or not following the MAY
>> in each case?"
>>
>> Regarding RFC 6425, I was looking for text along the lines of why one
>> would choose to implement this draft rather than 6425 (or both), to give
>> product implementers and network operators guidance on whether to use 6425,
>> this draft, or both for MPLS p2mp data plane failure detection. Otherwise,
>> why would they bother with this draft when they already have 6425 working?
>>
>> Also, in sections 4.1 and 4.2, you just added another MAY to section 4.1,
>> but again, what happens if you don't do the MAYs in both sections? Why
>> would I want to do the MAYs? Why would I not want to? The text doesn't say.
>>
> GIM2>> I've expanded the text and section 4.1 of the draft now is as
> follows:
>     LSP Ping is the part of on-demand OAM toolset to detect and localize
>    defects in the data plane, and verify the control plane against the
>    data plane by ensuring that the LSP is mapped to the same FEC, at the
>    egress, as the ingress.
>
>    LSP Ping, as defined in [RFC6425], MAY be used to bootstrap
>    MultipointTail.  If the LSP Ping used, it MUST include the Target FEC
>    TLV and the BFD Discriminator TLV defined in [RFC5884].  The Target
>    FEC TLV MUST use sub-TLVs defined in Section 3.1 [RFC6425].  It is
>    RECOMMENDED setting the value of Reply Mode field to "Do not reply"
>    [RFC8029] for the LSP Ping to bootstrap MultipointTail of the p2mp
>    BFD session.  A MaultipointTail that receives the LSP Ping that
>    includes the BFD Discriminator TLV:
>
>    o  MUST validate the LSP Ping;
>
>    o  MUST associate the received BFD Discriminator value with the p2mp
>       LSP;
>
>    o  MUST create p2mp BFD session and set bfd.SessionType =
>       MultipointTail as described in [I-D.ietf-bfd-multipoint];
>
>    o  MUST use the source IP address of LSP Ping, the value of BFD
>       Discriminator from the BFD Discriminator TLV, and the identity of
>       the p2mp LSP to properly demultiplex BFD sessions.
>
>    Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD
>    be used to verify the control plane against the data plane
>    periodically by checking that the p2mp LSP is mapped to the same FEC
>    at the MultipointHead and all active MultipointTails.  The rate of
>    generation of these LSP Ping Echo request messages SHOULD be
>    significantly less than the rate of generation of the BFD Control
>    packets because LSP Ping requires more processing to validate the
>    consistency between the data plane and the control plane.  An
>    implementation MAY provide configuration options to control the rate
>    of generation of the periodic LSP Ping Echo request messages.
>
>
>> Finally, in section 3, the following sentence doesn't scan:
>>
>>    The source IP
>>    address MAY be drawn from the IP header if BFD control packet
>>    transmitted by the head using IP/UDP encapsulation as described in
>>    Section 3.1.
>>
>> Did you mean "uses" instead of "using"?
>>
> GIM2>> Yes, it does need re-wording. Would this be better:
>  If BFD control packet encapsulated in
>    IP/UDP, the source IP address MUST be used to demultiplex the
>    received BFD control packet as described in Section 3.1.
>
>>
>> Thanks,
>> Andy
>>
>>
>>
>>
>>
>> On Tue, Oct 30, 2018 at 11:05 AM Greg Mirsky <gregimirsky@gmail.com>
>> wrote:
>>
>>> Dear Andy,
>>> thank you for the review and the detailed suggestions. Attached please
>>> find the updated version of the draft and the diff to highlight the
>>> proposed changes. Please let me know if these address your comments.
>>>
>>> Kind regards,
>>> Greg
>>>
>>> On Wed, Oct 24, 2018 at 11:11 AM Greg Mirsky <gregimirsky@gmail.com>
>>> wrote:
>>>
>>>> Dear Andy,
>>>> thank you for your thorough review and the most helpful comments. I'll
>>>> work on the update to address them.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Wed, Oct 24, 2018 at 9:17 AM Andrew G. Malis <agmalis@gmail.com>
>>>> wrote:
>>>>
>>>>> I’ve been selected as an MPLS-RT reviewer for
>>>>> draft-mirsky-mpls-p2mp-bfd-04, which is currently a candidate for MPLS WG
>>>>> adoption. This draft documents procedures for using BFD for multipoint
>>>>> networks to detect data plane failures in MPLS p2mp LSPs.
>>>>>
>>>>> The BFD WG has been working on draft-ietf-bfd-multipoint, which
>>>>> describes BFD procedures for multipoint and multicast networks.
>>>>> draft-mirsky-mpls-p2mp-bfd uses that draft as a basis to detect MPLS data
>>>>> plane failures for p2mp LSPs. This is a straightforward and useful
>>>>> application of the BFD draft for MPLS data plane failure detection.
>>>>>
>>>>> However, I would have expected to see at least a reference to RFC
>>>>> 4687, "Operations and Management (OAM) Requirements for Point-to-Multipoint
>>>>> MPLS Networks", and some text on how this draft addresses the requirements
>>>>> in that draft.
>>>>>
>>>>> I also expected more text on the relationship between this draft and
>>>>> RFC 6425, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS -
>>>>> Extensions to LSP Ping"', and more of an explanation of why the keyword MAY
>>>>> is used in sections 4.1 and 4.2 - what are the implications of following or
>>>>> not following the MAY in each case?
>>>>>
>>>>> The draft also needs an editing pass, for example "MaultipointHead"
>>>>> for "MultipointHead" and some incorrect English grammar in several
>>>>> places.
>>>>>
>>>>> Once these items have been addressed, I think that the draft should be
>>>>> ready for an adoption call.
>>>>>
>>>>> Cheers,
>>>>> Andy
>>>>>
>>>>>
>>>>>