AD review for draft-ietf-bfd-multipoint-active-tail

Martin Vigoureux <martin.vigoureux@nokia.com> Fri, 18 May 2018 17:35 UTC

Return-Path: <martin.vigoureux@nokia.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 E07B112D95D; Fri, 18 May 2018 10:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 TeY1AYTrQX-5; Fri, 18 May 2018 10:35:46 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD40D12D942; Fri, 18 May 2018 10:35:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yIjMPjaM+YQWoJmNi/nqIZmf2Kts8UrrZk6FwOyR2Ks=; b=hWLRe5iiUSPCTwfcX3nMWq7LgkUTJlFU7ACer63ukO9Vkoraf+MdS9+MArUszg4D6+n4EEu6+XwEOIe6Dgt/zBKC45T2UUknYN0/lRTLvgHKBqy+nOjRBgBBzD9G6F29FMpk49Tb4ZS+l+mcLlRRV9xv7Avhnq1E8EGxLlvzhVk=
Received: from [IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65] (2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65) by VI1PR0701MB2511.eurprd07.prod.outlook.com (2603:10a6:800:6f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.5; Fri, 18 May 2018 17:35:39 +0000
From: Martin Vigoureux <martin.vigoureux@nokia.com>
To: draft-ietf-bfd-multipoint-active-tail@ietf.org
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, rtg-bfd@ietf.org, bfd-chairs@ietf.org
Subject: AD review for draft-ietf-bfd-multipoint-active-tail
Message-ID: <04c76bec-ed2d-c3b1-6b92-b31d6a5ff620@nokia.com>
Date: Fri, 18 May 2018 19:35:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-Originating-IP: [2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]
X-ClientProxiedBy: PR2P264CA0001.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101::13) To VI1PR0701MB2511.eurprd07.prod.outlook.com (2603:10a6:800:6f::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(48565401081)(2017052603328)(7193020); SRVR:VI1PR0701MB2511;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2511; 3:RuPIzQy0jcuk1xOJc70vf/l85RmR0lSKhRUhvOyhw5sy2dXM4NrlvO7LqYqQJ0O4W1GC91YwNn/vyesSqLiSCoMszgT/Stay9sVmjI2JnOcgCGlwQamasBXNXMuzCrzTlrIg2gwVzXiBsxN/yuF6Jnace1S9SrQa/OjaUWUeSIoYZ4hR+EY7yQDox3+Ld6GTET/iMpM4hO9rXuttJA9Krb/NaD4JDJXULWTSL5OyDujfK36Q0xAjNhqVMoLxchag; 25:3nLgDZGvmabivJT043x7lsxL2BYkbjbesS2HL+ZL7utMlyYFIUfVdnTFycQLLH7Oc0vmXGIHpleFstedlw61T87RTGn2DVdG/NPH7YKdMoKsSB2eo7YpyBqd2/lsaHw6WuQ81gjs7AfJ3cRJPUZ4gk+xLepXsop7Zp5FFUSGa0nnkaQyLapHYFwhJnN447v4aOLSj4wlIJsLJCZWEVe/iBcZFNlNLkounh1kKjFXh/sb6vxbAdj0UXwWECV3p9ayhJOkoVsfWw4L/z2n3YAcH0IWCDTAVvW5eImALehWweWJfKKJaRnbXRPs49P/9bmAhWE7X67QsJNZZ2HFM35tvw==; 31:H6mMvEKgJglfxUPh6JAxga9wEFi3k4ZRiRq34MuxOSuE/xNCIskxZmWefQtdL3TO8Qc0eg80uhragPVMQiVZjjkDXgyoqGsUSdpybIp8oCR5Lz2na5bp6KNQLuNHVK5FMPHtVK2QLwnBYxK923PVRXb7dFhp2SITO6LEptIKO2TN3/OaGDxIxsqHShwVLafBfOLdVCWuXKKblzeri1VT3V8EIv5V+HykVyPhoM9gzCQ=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB2511:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2511; 20:ATaGDmHvUfzrYpf94BgsfSZ67rKMzJCJZK92Ade7AHh8JQRjRsVpRD4wr+gbH/edOKTrtXRhEz+RtgCkuiJHb1J7njZYZm2GLWCnR2vv6L2Lj3PmfxVVCFKYo2wkgf9/+6JU/kek1ZVe4ZxLqypaU26uXhvEXNVfM8kqhghQqbf+SmjGgUjk0ij0/8sujzEik0vYS6PhMhK5OLyc84UFQDbWBtBO8uWSERoduBpx3qkgJ2yCfylkC/svS2UiPK8l2m2g8R4Kze7iW4r40JtvkhD8svDxT0Ub1fn4AIA9v8O8g2MityhB7XWhnh+sM3/OOmBF7KhDqr9hhJN32ltIVIufZCZwaItdXPU9bEdyRTP3LyDiZfZ/D17sNHfkJp8sSEl/9hyIm6w7L7A8j2ADYkUKZizWV0sShPQKQEDguQGjVXynYRxlwpYX3WV3WkEDNamqBrWO+f1b4YrSuWOGDeK+TLgTSc0HmzUhtuB0yXsAhwcOWKeWOhHbOWm3aEp8; 4:RRqQVwor1VRasJIxIedzwsXxipqklWXI3pKMYwas/HLABgnKU8WRn9Y0EYjv4+PActn/gFikPfqj9+TzVCynUWrLNEIfK0LYGntnn1hGyYb2Nj80epRskwvnT5XTpThIRbM0jswHOhV+NR2DIJ80LSXUvjE5sgCPlIaPeJRZrfvmN4OBqeQnfbANWCzaCfRs+3r50k4UK5MFE6RgT/VMQxnWS10Fn63vltxSujTMRloNuTmOF3E0vKANt0bt934mDcBUkzGsg1aVdwej9V3zLawpgWQCSUxXKIpSLuh5MJHjnDhU7IvzNk5dP/EpO6wX
X-Microsoft-Antispam-PRVS: <VI1PR0701MB2511F61A3FE45E7A810641228C900@VI1PR0701MB2511.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(192374486261705);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2511; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2511;
X-Forefront-PRVS: 0676F530A9
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39380400002)(39860400002)(396003)(60444003)(51444003)(189003)(199004)(106356001)(59450400001)(6116002)(46003)(6486002)(2351001)(2361001)(1706002)(64126003)(386003)(52116002)(31686004)(2486003)(52396003)(52146003)(23676004)(305945005)(6666003)(6916009)(58126008)(50466002)(53936002)(2906002)(36756003)(7736002)(105586002)(316002)(230700001)(4326008)(67846002)(65826007)(2616005)(3260700006)(25786009)(486006)(5660300001)(97736004)(186003)(476003)(16526019)(345774005)(44832011)(47776003)(86362001)(81156014)(81166006)(31696002)(8676002)(478600001)(68736007)(65956001)(65806001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2511; H:[IPv6:2a01:cb04:a1a:4c00:f443:6b8b:e1f8:5e65]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;VI1PR0701MB2511;23:sVLAo5nA/AikLEN2kUaqv1GpMBpdr8WR6xfQ3wH9Ztj1HUi57LyZFj9gPdIMYUX2GwVwXzx742DNHcmsq5lY0tnvUSRzC/yGwI7tpA0C3DVLz17ymKUoR1Ipkr0BF/QY0nPGfK3maVbGTkuU01bCJFidlHc2i1oEbhNMn0droUIimA65vF83eZgeZUx5zu2SQsBm5E61ZIHXKNjddr26fW4ocN4rw6RP6t8CI+Le/NXTk+86pCdWBTxXvzkbjkWIRfrIz9cmZ71gX49yiJq4YehBZaI4AhwxbzovJhaDBcsjCyDY5NmVg1PG4zm6fH5oJFO2WkjQY+MdeDehN/YQQ066WBDtJeOQQBPYqPpgRSl6YrBVkbllxlBs68XhKiYymvmPS1ugdxv5d0nHobYbQbNXS7Dsbiz/7B0iv5qE7fpJGxN1vAVgxvsczfWRhOhzq3pVEJamN+n4DtBrzwMwJnxL5t7TAVFuT3k7aIFLG1WbDYpRoyObx/xu+kV1CkscWp60KIBgnvi+nVCdVA4MOCXFL+4vmQppFwqVh130mejNflLxrMId8lw+ddakG3rhVtHqTLCe2t5SDFUcc0iy3j9uvRPgZDoW/DMDnjSOjYUHXa4oWjUabYv3FUiIOP7plnI2ds64KCia+sn/fRw07PrNipbIDN2R6YPgHdW0LWNKIQdB3Ls9djgssTSvHBniYypVnePTbP8dUtTEf30NV1CXkdCodcDOh9v0YYfsCwqT7oKgXPhJCcgkYNRZDyvn/NH5DUHloVi9EH1ngoKTW0iui17COiRi0zxFQr/f7g6a/3kej5hSEgEPUFghvs678BdQfOa9jEckKz/QhK9yaef1UyQSiLFftmDEFlnMMvu+vJdTGN9giyDKL7dukrJCQ/nKrIqoSEg+J4sxdSQNbSz0nJWkupUWoOhw+hbkFFkyFAKTnoleCb+NQqMr0rULigJNu+9SsSmTTgW2lzeYixNrmXI+ORqN5L0gCBr+DBB700N8UrWBoRmlTh+RmGuoxoCj0UQFKMxyC47XI+OSmKU6oYdSfNQ7zDPIf/IjmzOjUIpTg3EV8MRREkXMNK5bTA9ZcHDs72QgzzcgVQ/lqGxN2Qb03cMkB2bOT9b63WlGFDGwJVll9Zk90zJOfWvLo34MX9F94XreLICjA7jLhJrOoTW9KCbpeavwOnsLmG/Yarvl4Q0Kx7g76/sWUz1JBMvJvRsfVNcqTyw09TlPB3QBQe2uEpsb5BimoJpBXAyEQzNV3yAnFC9JZL5QOxd9KKuZq8r62PzvyGumMfYxQVQVjutFjub+h0EHY3kkg8uojziOrSmysts6QvBFEiXyEt9TXRWFDECqghcQc+TAVUdqNV6is/ZYWQqy7ROzoY/ews6fbHVFK503ZggUlMymxzAmPfp9bob5Dwgw1SZL/w==
X-Microsoft-Antispam-Message-Info: dFVtGggLC53qvHCaTe2dwlDc0woeWA7b7XC/8cumFgt3RTHqA4/1H70fhOpQTJgmf9ZbeTHoW62PCQ7yNGB/StCl2OlWFG74Tb5MrR70zXszr9zioxGscap8AVljJWFFTxlKRiOZbmYj1yiTOnNaWhY1KGwNEu/hTcUnn9wPDDleu+2E0EdHcQG+ip4byC55qDRcOgjnXug1aQuHjxEQAJP4vbFH1Ji/HbqSvPX9uiuFM2SiPGR9ckgS7RYTItQC
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2511; 6:r9+AdI9lsPvfQWefqAh6FFBRiLSAkQAWr4bVvuzMqbjHi/U3QY/s4EdkjSO2Ktzac55KOfu+UH7s9CN/+Jq4R8TtJeHY8QYKCuxfjx1xO6vop30bbl9lAQGDGQAS6+2vtBawOJzjbDgidz6nQzbPDCqGeUhe11M210T0xYSyDY9uS5uwx0jYWHX2SlfFeG/nCmGCRVj+fca4owwHI/KTTaBjDA4Iu6QLUFoyuv4wVnn86J4rNYkrA8hQhy8sXKf7g6usUe8Zh/S8ahDGx+vl+NPLlapPPJP5x9qbi9pxaM09Lz5cPIzZy8loagglsvVZbIBaweiExSbrlCawTS1LJ7VqS2A73i/ODJZyOgtUnKr9yc3yQ3dTVLbckZZQRYmoga/jo1bFTjJiNI4Ttv/PV/ZOMQ5C/A1/zfXJNJcfhR4sdB7V8oO4IZWKV8OPDcrL6J/IPnhaR7JmGt9Y1ihspg==; 5:ObAeFNuhExO2/lmPetPCa9ch3Vsbt8xdhYwRuGyErGi/qkoqBZ4pc0w9L1LgXYDqAU4RE7yVFtialQ8W2XBGmA96emNWFp1qTWAHUwVHRmWlXE6SuUj8uxl90ZjxCaHMoFsEji9Hg836JtEKuKIKVYJAGRaNdx1nFduM87jLxv0=; 24:fFbBD/hLVwK23CnTqveBaZ5h0596qKqMscd3M4btLam61dDERiS/JZLtNF1qJWNzAmxA9nCW9MR4gXxoWyiu0MB9pw0yxNay2Z0lwq/GL7k=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2511; 7:C0aeAyu2poYtIrZx+JBj3noVrRnJT8Ph26MIzs28gvqylMZ+BLruqx5TqoJOvfVToVqgjD9EgqUty/b3gQ/EK5lJWdpvPSw1DpQK1OC+Dj+haOTCBRtG1kIdv2msWUnojb5uOceUaZA1heRa26RS+OVfb1MbGE5nItGvxM0HsklJ2ctfvzdWscNHeywDvhj24TQ/T+QeMKIYYUzNicpBe7CczWDJ9B/41ipp+R1uuSMYcrUD6heI94mMU7rquqeL
X-MS-Office365-Filtering-Correlation-Id: 0f763397-d370-4d7a-db04-08d5bce5c5f1
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2018 17:35:39.5676 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f763397-d370-4d7a-db04-08d5bce5c5f1
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2511
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ryIBKO7s1x9mQ_X-lQBnkthysSs>
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: Fri, 18 May 2018 17:35:49 -0000

WG, Authors,

hello.

thank you for this Document. I have done my AD review.
I find the document much harder to apprehend than mpBFD. I have a number 
of comments but may have another round of them based on your replies.

-m

---

General:
I find the use of reliable (and of its variants) not appropriate. You 
refer to reliability in terms disambiguating failure scenarios, you 
don't make packet transfer/delivery more reliable which is usually the 
context that comes in mind when talking about reliability. So I'd really 
prefer if you could use another word.

The discussion on fate sharing between unicast and multipoint paths is 
really reduced to the bare minimum while it is of key importance on the 
operation of the protocol and on the deduction the head can make of what 
it receives or not.


Abstract

Please specify here which document(s) this one updates. Please see 
further down on the Update point.


1.  Introduction

    Multipoint BFD base document [I-D.ietf-bfd-multipoint] describes
    procedures to verify only the head-to-tail connectivity over the
    multipoint path.  Although it may use unicast paths in both
    directions, Multipoint BFD does not verify those paths (and in fact
    it is preferable if unicast paths share as little fate with the
    multipoint path as is feasible, so to increase probability of
    delivering the notification from the tail to the head).
This is unclear. The first sentence sets the reader in the context of 
I-D.ietf-bfd-multipoint where unicast paths are not discussed at all. 
And the rest of this paragraph discusses the unicast paths which are in 
fact introduced later in this document. So this is totally confusing. 
One only understands this after having read the whole document...
I would suggest to completely remove, or rephrase to indicate to the 
user that this is an aspect that is introduced later, or move to the 
relevant place in the document.

    This document effectively modifies and adds to the base BFD
    specification [RFC5880] and base BFD multipoint document
    [I-D.ietf-bfd-multipoint].
In the same was as for mpBFD, I don't see how this document updates 
7880. Please clarify.
In fact I also think this document does not update 5880.
This document updates mpBFD so in principle that should be reflected in 
the header, but I'm not sure if we can reference anything else than RFCs 
there... But I'll push the two at the same time to IESG so that might work.
And one could wonder why these two documents are separate and not merged.


2.  Overview

    A head may wish to be alerted to the tails' connectivity (or lack
    thereof), there are a number of options.
Something's wrong with the structure of that sentence.

I find this:
    First, if all that is needed is an unreliable failure notification,
    as discussed in Section 3.2, the head can request the tails to
    transmit unicast BFD Control packets back to the head when the path
    fails, as described in Section 4.4.
somehow in conflict with what is said in 3.2 (to which the reader is 
pointed) and which says:
    In this scenario, the tail sends back unsolicited BFD packets in
    response to the detection of a multipoint path failure.  It uses the
    reverse unicast path, but not the forward unicast path.
On one hand you say "request" on the other you say "unsolicited", and 
just before that word you say "sends back" which gives a sense of "in 
response to". Could you clarify?
I have more comments on this section, and more precisely on the 
different modes of operations, but I'll discuss theses as part of the 
review of Section 3.x

In the two subsequent paragraphs a pointer to 3.3. and 3.4 would not be 
superfluous.

    If the head wishes to know the identity of the tails on the
    multipoint path, it may solicit membership by sending a multipoint
I don't think it is appropriate to talk about identity and membership. 
Head is polling a set of tails. You can't say much more than that.


    Individual tails may be configured so that they never send BFD
    control packets to the head, even when the head wishes notification
    of path failure from the tail.  Such tails will never be known to the
    head, but will still be able to detect multipoint path failures from
    the head.
ok, but how does the head knows of this config? How can the head 
distinguish between a failure and this? I guess the answer is oos of the 
document but I think that this situation is worth more than 4 lines.
Or is there a requirement that a Head SHOULD/MUST NOT have a 
MulticastClient session with a tail who is silent?


3.x Operational Scenarios

I find the description of the different modes of operation quite 
confusing. Beyond this I have other comments/questions on 3.x that 
you'll find after.
3.1 is plain multipoint BFD I guess. Correct?
In 3.2 you say that tails send packets to the source when they detect a 
failure (stop receiving packets). At this point of the reading it is not 
clear which element makes a difference between 3.1 and 3.2 such that, 
suddenly in 3.2, tails can send packets.
I believe it is worth clarifying that, though not giving too many 
details. Relates to 4.4?
Also at this stage it is not clear what are those packets that tails 
send in 3.2. Are they replies to Polls? If so what is the difference 
between 3.2 and 3.3?


3.1.  No Head Notification

You say:
    Since the only path used in this scenario is the multipoint path
as if it had been stated before that this scenario only uses the mpPath.
It would be much more comprehensible if it was saying:
    In this scenario only the multipoint path is used.


3.3.  Semi-reliable Head Notification and Tail Solicitation

You say (twice):
    the head will see the BFD session fail
Could you clarify which session fails,?


3.4.  Reliable Head Notification

same comment as for 3.3


4.  Protocol Details

    This section is an update to section 4 of [I-D.ietf-bfd-multipoint].
Should you rather say that it's only some parts of this section which 
update mpBFD, and say which ones.


4.1.  Multipoint Client Session

    If the head is keeping track of some or all of the tails, it has a
    session of type MultipointClient per tail that it cares about.  All
    of the MultipointClient sessions for tails on a particular multipoint
    path are grouped with the MultipointHead session to which the clients
    are listening.
What do you mean by "grouped", associated?

    These sessions receive any BFD Control packets sent by the tails, and
    never transmit periodic BFD Control packets other than Poll Sequences
    (since periodic transmission is always done by the MultipointHead
    session).
Should it be "MUST never send"?

    A BFD Poll Sequence may be sent over such a session to a tail if the
    head wishes to verify connectivity.
It is not clear here if you are talking about sending a multipoint Poll 
sequence to all tails over the MultipointHead session or a unicast Poll 
sequence to a single tail over one MultipointClient session.


4.3.2.  New State Variable Value

       This variable MUST be initialized to the appropriate type when the
       session is created, according to the rules in section 4.13 of
       [I-D.ietf-bfd-multipoint].
There is nothing in 4.13 of mpBFD that talks about the initialization of 
bfd.SessionType.


4.3.3.  State Variable Initialization and Maintenance

    Some state variables defined in section 6.8.1 of the [RFC5880] needs
    to be initialized or manipulated differently depending on the session
    type (see section 4.4.2 of [I-D.ietf-bfd-multipoint]).
s/of the/of/
s/needs/need/
s/ (see section 4.4.2 of [I-D.ietf-bfd-multipoint])./. The values of 
some of these variables relate to those of the same variables of a 
MultipointHead session (see section 4.4.2 of [I-D.ietf-bfd-multipoint])./


       bfd.RequiredMinRxInterval
          It should be noted that for sessions of type MultipointTail,
          this variable only affects the rate of unicast Polls sent by
          the head; the rate of multipoint packets is necessarily
          unaffected by it.
what is specific to MultipointClient here? If nothing, please remove.
If something, please add it clearly.


4.4.  Controlling Multipoint BFD Options

    The most basic form of operation, as explained in
    [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only
    from the head and no tracking is desired of tail state at the head,
    is accomplished by setting bfd.ReportTailDown to 0 in the
    MultipointHead session (Section 3.1).
I am a bit concerned that mpBFD in fact works with a state variable 
defined in another document. Wouldn't it be better to introduce this 
variable in mpBFD and set it to always be zero and then allow in this 
doc to be set at 1. A bit like the M bit.

You have text relating to 3.1. What about 3.2/3/4?

    If the head wishes to know the identity of the tails, it sends
    multipoint Polls as needed.  Previously known tails that don't
    respond to the Polls will be detected (as per Section 3.3).
Again, I'd prefer not to talk about identity, but simply about messages 
received from tails or not.
I don't see the purpose of this paragraph here. What is the relation 
with state variables?

    If the head wishes to be notified by the tails when they lose
    connectivity, it sets bfd.ReportTailDown to 1 in either the
    MultipointHead session (if such notification is desired from all
    tails) or in the MultipointClient session (if notification is desired
    from a particular tail).  Note that the setting of this variable in a
    MultipointClient session for a particular tail overrides the setting
    in the MultipointHead session.
Does that correspond to 3.2, 3.3, 3.4?

    If the head wishes to verify the state of a tail on an ongoing basis,
    it sends a Poll Sequence from the MultipointClient session associated
    with that tail as needed.
    If the head wants to more quickly be alerted to a session failure
    from a particular tail, it sends a BFD Control packet from the
    MultipointClient session associated with that tail.  This has the
    effect of eliminating the initial delay, described in Section 4.13.3,
    that the tail would otherwise insert prior to transmission of the
    packet.
I don't see the link with state variables here neither. Consider moving 
somewhere else.

    If a tail wishes to operate silently (sending no BFD Control packets
    to the head) it sets bfd.SilentTail to 1 in the MultipointTail
    session.  This allows a tail to be silent independent of the settings
    on the head.
The implications of that option are not really discussed. The head will 
likely consider the session down, no?


4.5.  State Machine

    The state machine for session of type MultipointClient is same as
    defined in section 4.5 of [I-D.ietf-bfd-multipoint].
Is that really the case? MultipointHead only fails administratively 
while MultipointClient can fails based on received message, no?


4.6.  Session Establishment

    The head directly controls whether or not tails are allowed to send
    BFD Control packets back to the head.
Not fully true, because of SilentTail, no?


4.13.1/2/3

I think that, as said, you are not updating 5880. Also, you said that 
you update sections but really you are updating parts of them.
I encourage you to find a clear way to indicate what you change/update.


7. Security Considerations

Can't you elaborate a bit? This look a bit like the bare minimum.
---