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

Greg Mirsky <gregimirsky@gmail.com> Mon, 19 November 2018 16:43 UTC

Return-Path: <gregimirsky@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 2A18E130DDD; Mon, 19 Nov 2018 08:43:16 -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 f9zG1jjGMp3M; Mon, 19 Nov 2018 08:43:12 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 7C1F5130DD3; Mon, 19 Nov 2018 08:43:11 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id v15-v6so26693532ljh.13; Mon, 19 Nov 2018 08:43:11 -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=hz3s3dN1PJackMwAEFU2Csrn3vojWeXHF1cizp3rQkE=; b=F7Q0+vFzWiTL8wVr/d3lQX9Zwt00jJwYhpaZbO8vWr6uVicdUMu19TCt+KP1eDDtxs RHD6AU96EHHWOQmRqZdSGnS443DhNiji9QR7I1GjoJRNl4Go0gN/PnUz64NuXQNvVhqK RB5WaVzJ8FdX2iuQgnuoSbvvrQNnF5iUBBLzFt+oxfFWWq6nxlRnHEWN3c14VHHAtuJc l78kD0rtk79WLty+ISieNl8PYHLG07z3ssQ1vxxuv1b9aGp+eh/S67pRCW3NNDAFVraj 7Txh+u1K2Po9rZLthjSbD94CI9tFau4O4pkc/2Rf3TNn1YaZv5zx0DJAPoKjn2lo1UeM jV7w==
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=hz3s3dN1PJackMwAEFU2Csrn3vojWeXHF1cizp3rQkE=; b=oUXdsDyiczD/m0UIgwUDvc6DObgeX/cq2ftIoTiHV+NnJTZHVVml0m2m2GRTGq6Ie5 +l1r06zF6KI7COI6INZ67fNlbi9F7BreQdXipii6+6p2Gu3sksGPUmYTzd4GEJm3z7xG aVnrxCV8+DkPn2kbk5aHaZ40ic7eziQhs+qvOIPI4hd8wmIYzLALJ0J3T7dSKANd19bd pCzzlNglKO2ExWZgxGAYIkuo/5968NaJTemkMQXly54TFHv9L27N3aXEwrsXQqpZitUv 4rwiFwpWj/UTfuaix/Gr7iflpRk6+KtcXKQ2cf3v9Ze3e5h6n6i8QvUfQ0KQXk+p/anx FBKg==
X-Gm-Message-State: AGRZ1gLZJbT3Hvfbhx6TmVamD9O62GfeI3eg7i2FINfUHHl4VecyvrUY JQezUpCVXfP8Sfe6v0eKvE3RAlj/NTt1OVulQ9g=
X-Google-Smtp-Source: AJdET5e7REvN8DGsK5KNWbjpT2sQapiEg/bDFNTF2vsUFzmAphl2S90lCLGxVO2YkUyDJ8UoBpwRSUIDE1EAIgwTKyo=
X-Received: by 2002:a2e:9c52:: with SMTP id t18-v6mr9858180ljj.149.1542645789345; Mon, 19 Nov 2018 08:43:09 -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> <CAA=duU0tD-FU84AXLTZwjHEfUwcV2UCZhOOWGJbfU40jXYujpQ@mail.gmail.com>
In-Reply-To: <CAA=duU0tD-FU84AXLTZwjHEfUwcV2UCZhOOWGJbfU40jXYujpQ@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 19 Nov 2018 08:42:57 -0800
Message-ID: <CA+RyBmVtZ8E42DUNWm5grLc13ZddVh88=G5sE6ZbDHiN=z=ckQ@mail.gmail.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
Cc: mpls-chairs@ietf.org, draft-mirsky-mpls-p2mp-bfd@ietf.org, mpls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000049cc67057b0736ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_-xQVOuGJEj9sqWWFHbIup75q30>
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:43:16 -0000

Hi Andy,
thank you for your help and patience. Will do as you've suggested.

Kind regards,
Greg

On Mon, Nov 19, 2018 at 8:23 AM Andrew G. Malis <agmalis@gmail.com> wrote:

> 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
>>>>>>
>>>>>>
>>>>>>