Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2mp-bfd-04
Greg Mirsky <gregimirsky@gmail.com> Sun, 18 November 2018 22:13 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 4A36D127598; Sun, 18 Nov 2018 14:13:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=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 qmWaZghGtH3i; Sun, 18 Nov 2018 14:13:11 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 5374B126BED; Sun, 18 Nov 2018 14:13:10 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id u6-v6so24532264ljd.1; Sun, 18 Nov 2018 14:13: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=yejWV6nuhLHAtrxzUKnlURmpmXYfhpsP3Ufe/QSulic=; b=ArEQY8aXN5roWAk7dHW9bFtu/Yrv2zGSBSkkWIAvyz4UT77lDjXcx73tEAN/yOKvTu lb2hfADc/m2EqteY0s4VJ1nxAQ2lzeQVbaG7OTMeqBYsj9mTKZY0zXlcZTWOBGfzfL9f 1EnvA5ZhXVkFU9XEROQbwkkp/VwahJQ73+Y/CZybvl5IimDdLLHj3E1og/zURBcdr+UT KQ5zzi7vaZCSCG/g3hub1Q0UrERHUG4GQBWQmXoT+L/wktryOTYytnKKVkRz1fm7Tben EuaKzzYm+ggRwnknk1BhXuI81DXRabGXuza9wfVspcuP5cSwOwTZ4w0Fa7ukw/CzLMaH NUKQ==
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=yejWV6nuhLHAtrxzUKnlURmpmXYfhpsP3Ufe/QSulic=; b=oqz+YM8FJSgt3WmMFp/FPTLjkNaYpR/nkaYonx5rn/14hCb3VQ5vrF6okXqPevflRD g/umuOBHSpmm7DbQ1OMEFLE3HooqypJDDwTGkT8t395Ckq/xqa64ND/NcY6IGFkqvq84 9Qde8X0/Bhl/0mz1fuDAFHwpO9qYRspEkWtP315NArxvjCvrmaI4gU4H7lZjkWl0/sK1 60ioq0KFMCjxI9hWEwHf3lxHPgPkcufbMuxQxzHFyou5nyv6QRpUhZXABm5NNHsOMCOJ BElIscJBEyclyiJcxBf3/IuFayMrnQ8S5cLSZnYMjWeDZ8rjNfhnCYUhBw3H5ofQpITA drZg==
X-Gm-Message-State: AGRZ1gLeY7PC6QeHMxr3hbf0WBAzCEzTH69EJjM9CLY5BVwyyv8ahjH/ gsIDetOd36eb2/ePpfVCIr4xei0nvaCHnK1nvhw=
X-Google-Smtp-Source: AJdET5cdklKNrh6JuGLdXct6lnAk3clIFuZvaYQd606Ab+NMfdDiJ88wNGtpu4A6iqYYf4nt7aSDbpIbLqhLYfzaPSM=
X-Received: by 2002:a2e:851a:: with SMTP id j26-v6mr10001513lji.163.1542579188174; Sun, 18 Nov 2018 14:13: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>
In-Reply-To: <CAA=duU3eaXNPhSddxDxzrazL8NSwsVpR2TtkxLqH3YODBf=3Yw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 18 Nov 2018 14:12:57 -0800
Message-ID: <CA+RyBmUv=Vni=U3skpk-KujTGVdX9Gz88_+G3tj+jtco+qYijw@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/mixed; boundary="0000000000008cdfa5057af7b403"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/rjUwUoJ7HgZRYh56N2aJiGcAlaA>
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: Sun, 18 Nov 2018 22:13:15 -0000
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 >>>> >>>> >>>>
- [mpls] MPLS-RT review of draft-mirsky-mpls-p2mp-b… Andrew G. Malis
- Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2… Greg Mirsky
- Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2… Greg Mirsky
- Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2… Andrew G. Malis
- Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2… Greg Mirsky
- Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2… Greg Mirsky
- Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2… Andrew G. Malis
- Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2… Greg Mirsky