Re: Tsvart last call review of draft-ietf-bfd-multipoint-16

Bob Briscoe <ietf@bobbriscoe.net> Tue, 29 May 2018 10:23 UTC

Return-Path: <ietf@bobbriscoe.net>
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 B96A61270A3; Tue, 29 May 2018 03:23:04 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 aBWpvho7vEVj; Tue, 29 May 2018 03:22:58 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40ECF126D05; Tue, 29 May 2018 03:22:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2S5qFTKOvvIP3DhscK+DQ4Z/dpxM/xcANp6+j6MGwEw=; b=vGTbkws6EztOM3suthW+7kaF+ Edcq5em3x1yqznZFLsQdmixKtvzyc63acBNlL2pGDcozwtQRK3Eofv7WX+kjgvjqyAmFTFfJ1YnlN rwMJvwZsdSuhuHwCwk8FOV5ChqCANWoPvIveBtY97morPtRcYPu++z7bQVoqZvoufG2PQ8t18qXHn N2tLD1sCB+RZtHGpuGwVB26TIXJ5Vf8o0GOuFiEU3H2q1aY6Ro9lSbKGKY4XgZoc5F9+NFHxuwHwt hapou+/nP/RAbvEo1HS5vwjmvaficqDdN9OuNtDBefAo9f6RI/VigIU9INsjlvnMPuwy4+Hd2Mytu /8F+VdWTA==;
Received: from 165.26.112.87.dyn.plus.net ([87.112.26.165]:60398 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <ietf@bobbriscoe.net>) id 1fNbmH-0005pC-Pl; Tue, 29 May 2018 11:22:54 +0100
Subject: Re: Tsvart last call review of draft-ietf-bfd-multipoint-16
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: tsv-art@ietf.org, draft-ietf-bfd-multipoint.all@ietf.org, rtg-bfd@ietf.org, ietf@ietf.org
References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <CA+RyBmVmsFxmiDTLLS5Jz+q_Fgb3O7QcsbMJwFUxbh-+9XxYWQ@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net>
Date: Tue, 29 May 2018 11:22:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CA+RyBmVmsFxmiDTLLS5Jz+q_Fgb3O7QcsbMJwFUxbh-+9XxYWQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------52421336449A8A1E502ED409"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ujA_wXaD2YX-OHKjmbas23vozm4>
X-Mailman-Approved-At: Tue, 29 May 2018 04:43:02 -0700
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: Tue, 29 May 2018 10:23:05 -0000

Greg,

On 26/05/18 20:49, Greg Mirsky wrote:
> Hi Bob,
> thank you for the thorough review, detailed questions and helpful 
> comments. Please find my answers in-line and tagged GIM>>.
> I've updated the working version of the draft based on your comments 
> and suggestions. Appreciate your feedback whether all questions have 
> been addressed.
> Attached please find the diff of -16 and the working version and the 
> copy of the working version of the draft.
>
> Regards,
> Greg
>
> On Mon, May 21, 2018 at 5:20 PM, Bob Briscoe <ietf@bobbriscoe.net 
> <mailto:ietf@bobbriscoe.net>> wrote:
>
>     Reviewer: Bob Briscoe
>     Review result: Not Ready
>
>     Altho this is a TSV-ART review, I did not find many
>     transport-related issues to
>     focus on, except a need to justify why lack of information for
>     adapting the
>     transmit interval is not an issue.
>
>     Nonetheless, I did find a few other non-trivial technical issues,
>     including 2
>     security issues, enumerated below (I mis-spent some of my early
>     research career
>     working on a multicast session control and security, for which we used
>     beaconing control channels). However, I only have passing prior
>     knowledge of
>     BFD, so my critique might be off-beam.
>
>     ==Main Technical Concerns===
>
>     1/ Mandatory return path?
>     RFC5880 is the base RFC that this draft updates. RFC5880 says that
>     "unidirectional links" are in scope, but only as long as there is
>     a return path.
>
>     The introduction of this bfd-multipoint draft seems to contradict
>     that, making
>     a return path optional: "
>        As an option, the tail may notify the head of the lack of
>     multipoint
>        connectivity.  Details of tail notification to the head are outside
>        the scope of this document.
>     "
>     It's allowable for irrelevant details to be outside the scope, but
>     surely it
>     needs to be clear whether at least the existence of a return path
>     is mandatory.
>
> GIM>> Thank you for highlighting this issue. I think that the second 
> paragraph of Introduction is the appropriate place to note that this 
> mechanism does not require existence of a return path from tails to 
> the head. Would the following be acceptable:
> NEW TEXT:
>    Use of BFD in
>    Demand mode enables a tail monitor availability of a multipoint path
>    even without the existence of some kind of a return path to the head.
>
>
>     2/ Mechanism for verifying connectivity, or not?
>     The introduction seems to contradict itself:
>     "
>        As multipoint transmissions are inherently unidirectional, this
>        mechanism purports only to verify this unidirectional connectivity.
>     "
>     "
>        Term "connectivity" in this document is not being used in the
>     context
>        of connectivity verification in transport network but as an
>        alternative to "continuity", i.e. existence of a forwarding path
>        between the sender and the receiver.
>     "
>     How can this mechanism verify connectivity, but not be used in the
>     context of
>     connectivity verification in the transport network?
>
> GIM>> This draft defines the base specification for multipoint BFD. In 
> order for multipoint BFD to support the transport-like connectivity 
> verification we need to do work similar to described in RFC 6428.
[BB]: Caveat: I am having to talk in generalizations, cos I don't 
actually know how you are going to get this protocol to work in a wide 
range of circumstances, given inherent problems like multipoint feedback 
implosion {Note 1}.

My point was that, having broken up the drafts in this way, this draft 
on its own no longer defined a workable protocol. Therefore, it needed 
some references to other drafts (even if they are placeholders), so that 
the extent of the pre-requisite collection of work is clear. The refs 
you give later go a long way to fixing this issue.

If each pre-requisite protocol is intended to only represent one 
example, the citation can say that and the ref can be informative. But 
with zero examples for all the prerequisite parts, all the reader sees 
is a dismembered octopus, not a protocol.


>
>     3/ Use case
>     The introduction seems to be written rather academically. Surely,
>     in cases
>     where there is never a return path, only the tails will ever be
>     able to verify
>     connectivity. The head could continue transmitting BFD packets
>     (and data
>     packets) for years without ever knowing whether it is connected to
>     anything.
>     Knowledge of connectivity is surely of little use if it excludes
>     the link
>     sender, which is the node that always controls routing.
>
>     If there are scenarios where it is useful for tails but not the
>     head to be able
>     to verify connectivity, can you please give a concrete example?
>
> GIM>> One example could be a multicast system with 1+1 protection. 
> Without multipoint BFD tails would not be able to detect the failure 
> of the muticast path from the head. Other examples discussed in 
> several drafts:
>
>   * BESS WG draft MVPN fast upstream failover
>     <https://tools.ietf.org/html/draft-ietf-bess-mvpn-fast-failover-03>
>   * Individual draft BFD for Multipoint Networks and VRRP Use Case
>     <https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-01>
>   * Individual draft BFD for Multipoint Networks and PIM-SM Use Case
>     <https://tools.ietf.org/html/draft-mirsky-pim-bfd-p2mp-use-case-00>
>
> I am not sure how references to non-WG drafts affect the progress of 
> this document. Appreciate your suggestion.
[BB]: In my experience, informative refs to non-WG drafts as use-cases 
would be OK during doc development. However, if a non-WG draft fails to 
proceed, its citation has to be removed later. So choose those that are 
most likely to proceed.

Nonetheless, if you cite some specs that turn this into a workable 
protocol (see previous issue) use-cases might not be necessary.

>
>
>     4/ Interval adaptation
>     Text is needed to describe why it is not an issue for the head to
>     be unaware
>     whether it needs to adapt its transmit interval. Otherwise, this seems
>     potentially problematic.
>
> GIM>> Very interesting, thank you. I wouldn't say that the case when a 
> tail cannot process incoming mpBFD control packets at the offered rate 
> is entirely non-issue. Such scenario must be handled by the 
> implementation and may be controlled by local policy, e.g., close the 
> MultipointTail session.
[BB]: Fair enough.

In some scenarios, this issue will not necessarily be so unlikely tho:
* If asymmetric crypto is used to solve the group message authentication 
problem (see later), the processing burden on any lightweight endpoints 
might lead to message verification leaving less available processor 
resource than needed for the host's other tasks.
* Each tail might be joined to a very large number of multipoint sessions.

> Where would you suggest to add the text?
I would suggest a new section listing potential issues when there is no 
back channel.


>
>     5/ Inability to authenticate the sender with symmetric keys
>     In unicast scenarios, symmetric keys can be used for message
>     authentication,
>     because each end knows there is only one other node with the
>     shared key. But,
>     in multipoint scenarios, all the tails would share the key, so a
>     shared key
>     does not authenticate who sent the message - any tail can spoof
>     the head from
>     the viewpoint of the other tails.
>
>     Therefore text is needed to say that:
>     * multipoint message authentication is limited to cases where all
>     tails are
>     trusted not to spoof the head, if shared keys are used. *
>     otherwise asymmetric
>     message authentication would be needed, e.g. TESLA [RFC4082]
>
> GIM>> Thank you for the suggested text. Would the Security 
> Considerations section be appropriate place:
[BB]: Well, the point limits the applicability of the assumption about 
security in 5. 'Assumptions', so this would fit well there.
Then "Security Considerations" should point to everywhere in the doc 
that discusses security, such as this (to save time for security reviewers).

> NEW TEXT:
>    Use of shared keys to authenticate BFD Control packet in multipoint
>    scenarios is limited because tail can spoof the head from the
>    viewpoint of the other tails.  Thus, if shared keys are used, all
>    tails MUST be trusted not to spoof the head.
[BB]: Normally a MUST is applied to implementations. It would be rather 
odd to require users/operators to satisfy a spec requirement, 
particularly requiring them to trust each other. I think this should be 
written as an applicability statement not a normative requirement.

> Otherwise, asymmetric
>    message authentication would be needed, e.g., Timed Efficient Stream
>    Loss-Tolerant Authentication (TESLA) as described in [RFC4082].

[BB]: If you are going to allow for cases where all tails are trusted 
not to spoof the head, then the assumption written in section 5 is no 
longer correct.

[FYI, RFC4082 is only a generic description. Many RFCs have been written 
to authenticate specific protocols along TESLA lines.]

>
>     A related nit: Section 5 says all tails are assumed to have a common
>     authentication key. In cases with symmetric message
>     authentication, surely the
>     head also needs the same key.
>
> GIM>> Thank you. Please check the updated text:
> NEW TEXT:
>    If authentication is in use, the head and all tails must be
>    configured to have a common authentication key in order for the tails
>    to validate received the multipoint BFD Control packets.
[BB]: Yup. Except delete "received the".
Also see above about whether this is now a correct assumption.

>
>     6/ Source address spoofing
>     A 3-way handshake makes a protocol robust against simple source
>     address
>     spoofing. Without a 3WHS, surely the spec. needs to highlight this
>     vulnerability or discuss ways to address it or why it is not an issue.
>
> GIM>> Because mpBFD control packets cannot be demultiplexed by  tail 
> based on the value of Your Discriminator field as per RFC 5880,
> the new procedure outlined in Section 4.7:
>    IP and MPLS multipoint tails MUST demultiplex BFD packets based on a
>    combination of the source address, My Discriminator and the identity
>    of the multipoint tree which the Multipoint BFD Control packet was
>    received from.  Together they uniquely identify the head of the
>    multipoint path.
> and described in details in Section 4.13.2:
>       If the Multipoint (M) bit is set
>
>          If the Your Discriminator field is nonzero, the packet MUST be
>          discarded.
>
>          Select a session as based on source address, My Discriminator
>          and the identity of the multipoint tree which the Multipoint
>          BFD Control packet was received.  If a session is found, and
>          bfd.SessionType is not MultipointTail, the packet MUST be
>          discarded.  If a session is not found, a new session of type
>          MultipointTail MAY be created, or the packet MAY be discarded.
>          This choice is outside the scope of this specification.
>
> Would you suggest additional text to a use case where the new 
> demultiplexing is not sufficent to protect from source address spoofing?

[BB]: I seem to have become co-opted into redesigning this protocol. I'd 
prefer to limit my involvement to reviewing :)


>
>     7/ Scope
>     On eight occasions an issue is raised, but resolution is stated as
>     outside the
>     scope of this document. It is OK to limit the scope of a spec, for
>     example to
>     allow for multiple solutions to each issue. But at least one
>     solution must
>     already exist for each of these eight issues. So, at least one
>     example solution
>     ought to be cited in each case. If any issues are open, then this
>     should not be
>     on the standards track.
>
>     It would be more useful to state why each issue is out of scope.
>     This would be
>     helped by stating from the start what the scope of the document is.
>
> GIM>> I've listed all eight occasions with the explanation for each one:
>
>  1. Details of tail notification to the head are outside the scope of
>     this document. - Notifications by tails addressed in
>     draft-ietf-bfd-multipoint-active-tail
>     <https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/>.
>     Will add as informational reference.
>
[BB]: Good.

Nonetheless, given you have confirmed that a reverse path is optional, 
the doc still needs to address the case where there is no reverse path.

{Note 1} For the active tail draft, you might find the following ideas 
for scaling multipoint feedback useful:

*Statistical feedback:*
Nonnenmacher, Jö. & Biersack, E.W., "Scalable Feedback for Large Groups 
<https://dl.acm.org/citation.cfm?id=312251>," IEEE/ACM Transactions on 
Networking 7(3):375--386 (June 1999)

FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for 
very large multicast groups 
<https://dl.acm.org/citation.cfm?id=2294709>," Computer Communications 
24, 5-6 (March 2001), 539 547;
WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast 
groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of 
Mannheim, Germany, May 2001.

Also, anycast can be used to select different representative feedback 
tails, e.g. for a certain time, which might overlap with the periods for 
which a few other tails are selected using subsequent anycasts.

*Logical 'AND' feedback:*
Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and 
device for co-ordinating networked group members 
<https://worldwide.espacenet.com/publicationDetails/biblio?II=0&ND=3&adjacent=true&locale=en_EP&FT=D&date=20060406&CC=US&NR=2006075022A1&KC=A1#>" 
Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002)
[AFAICT this patent is still being maintained, so use of it in a 
protocol would require an IPR declaration.]


>  1. Details of how the head keeps track of tails and how tails alert
>     their connectivity to the head are outside scope of this document.
>     - Same as #1.
>
[BB]: And my response is same as #1.
>
>  1. Bootstrapping BFD session to multipoint MPLS LSP in case of
>     penultimate hop popping is outside the scope of this document. -
>     It may use control plane as in MVPN draft. Will add as
>     informational reference.
>
[BB]: Good.
>
>  1. Use of other types of encapsulation of the BFD control message
>     over multipoint LSP is outside the scope of this document. - This
>     in reference to ACH encapsulation that is discussed in
>     draft-mirsky-mpls-p2mp-bfd
>     <https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-03>.
>     Should it be added as informational reference? What would be the
>     imacpt of progressing this specification?
>
[BB]: See earlier comment about citing individual drafts (I don't have 
enough BFD knowledge to give a BFD-specific answer).

Also, in my review I should also have said: when creating new 
encapsulations, pls see the common transport issues related to 
encapsulation:
https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#TunnelingprotocolsandTransportRelatedIssues


>  1. Change in the value of bfd.RequiredMinRxInterval is outside the
>     scope of this document. - Same as #1.
>
[BB]: And my response is same as #1.
>
>  1. If a session is not found, a new session of type MultipointTail
>     MAY be created, or the packet MAY be discarded. This choice is
>     outside the scope of this specification. - I propose to add "based
>     on local policy" to the last sentence.
>
[BB]: On what basis will local policy decide? It's my job as a reviewer 
to ensure that this spec does not contain any loose ends (open issues).

>  1. The exact method of selection is application-specific and is thus
>     outside the scope of this specification. - This is copied from RFC
>     5880: "The exact method of selection is application specific and
>     is thus outside the scope of this specification." as the section
>     is to replace Section 6.8.6.
>
[BB]: OK.
>
>  1. If a matching session is not found, a new session of type
>     PointToPoint MAY be created, or the packet MAY be discarded. This
>     choice is outside the scope of this specification. - Same as #6.
>

[BB]: And my response is same as #6.
[Sry, my embedded comments have broken your numbered list.]


>
>
>     There is also one issue that is "for further discussion". Does
>     this mean the
>     document is not ready yet?
>
> GIM>> I think that the question left for further discussion is 
> non-technical:
>    The semantic difference between Down and AdminDown state is for
>    further discussion.
> I propose to remove the sentence altogether.
[BB]: OK.

>
>
>     8/ Incremental deployment
>
>     Section 4.4.1.  "New State Variable Values" defines bfd.SessionType =
>     PointToPoint as well as a couple of Multipoint alternatives.
>     Presumably this
>     spec does not require all existing PointToPoint systems to support
>     this state
>     value. Is the implication that only Multipoint systems that happen
>     to be in
>     PointToPoint mode should use this state?
>
> GIM>> You're aboultely right, existing implementations of BFD don't 
> need to support bfd.SessionType variable. Only implementations that 
> support the base BFD, single-hop or multi-hop, and this specification, 
> mpBFD, should support bfd.SessionType and set it to PointToPoint value 
> when BFD is in single-hop or multi-hop mode. When in mpBFD mode, 
> bfd.SessionType will be set to either MultipointHead or MultipointClient.
[BB]: Doesn't something need to be written (or referenced) to clarify 
all this? AFAIR, this spec. never made clear that multipoint is a fork 
in implementations.


>
>     ==Nits==
>
>     * Sometimes 'tree' is used to mean a multipoint path in general. I
>     suspect
>     'path' was intended.
>
> GIM>> I've found six occasions of "tree" and s/tree/path/
>
>
>     4.8.  Packet consumption on tails
>     s/Node/Nodes/
>     s/packet/packets/
>     s/demultiplex/demultiplexed/
>
> GIM>> Accepted all three.
>
>
>     4.9.  Bringing Up and Shutting Down Multipoint BFD Service
>     "
>        a newly
>        started head (that does not have any previous state information
>        available) SHOULD start with...
>     "
>     ...
>     "
>        ... (so long as the restarted head
>        is using the same or a larger value of bfd.DesiredMinTxInterval
>     than
>        it did previously).
>     "
>     If it has no state available, how can it know whether a value is
>     larger than
>     previously?
>
> GIM>> You are right, the BFD system at the head would not know the 
> previous value of bfd.DesiredMinTxInterval. This text is to caution 
> operator from decreasing bfd.DesiredMinTxInterval upon restart of the 
> BFD system.
>
>
>     4.9.  Bringing Up and Shutting Down Multipoint BFD Service
>     There are a number of "SHOULD"s and "SHOULD NOT"s that do not
>     state or give
>     examples of circumstances in which the "SHOULD" would not be
>     appropriate. If
>     there are none, "MUST" would be more appropriate.
>
> GIM>> In the first paragraph SHOULD may not be followed if the 
> implementation can differentiate between the very first start and 
> restarts of BFD system. If it is the first start of BFD system, the 
> head MAY directly progress to Up state skipping Down state.
> The last paragraph describes graceful shuttdown. The head MAY shut the 
> BFD mp session abruptly by just stopping transmission of BFD Control 
> packets.
[BB]: I assume you will say all this in the next rev, not just in this 
email.

>
>     4.10.  Timer Manipulation
>     "
>        Because of the one-to-many mapping, a session of type
>     MultipointHead
>        SHOULD NOT initiate a Poll Sequence in conjunction with timer value
>        changes.  However, to indicate a change in the packets,
>        MultipointHead session MUST send packets with the P bit set.
>        MultipointTail session MUST NOT reply if the packet has M and P
>     bits
>        set and bfd.RequiredMinRxInterval set to 0.
>     "
>     The initial "SHOULD NOT" needs to be written another way. Perhaps
>     "
>        ...a session of type MultipointHead
>        does not initiate a Poll Sequence
>     "
>     The head's normative action is defined by the following "MUST",
>     then the tail's
>     "MUST NOT reply" is what prevents the poll sequence happening.
>
> GIM>> A Poll Sequence starts with the initiator setting Poll bit. 
> Unless the peer sends BFD Control packet with Finl bit set the poll 
> sequence would continue indefinetely. The initial SHOULD NOT, in my 
> opinion, correctly points that the mechanism of Poll Sequence not to 
> be used by MultipointHead when changing transmission interval. I think 
> that MUST in the first paragraph can be downgraded to MAY because the 
> MultipointHead doesn't need to use transition period when changing the 
> transmission interval to lower level, i.e., decreasing frequency. May 
> I propose the following:
> OLD TEXT:
>    Because of the one-to-many mapping, a session of type MultipointHead
>    SHOULD NOT initiate a Poll Sequence in conjunction with timer value
>    changes.  However, to indicate a change in the packets,
>    MultipointHead session MUST send packets with the P bit set.
> NEW TEXT:
>    Because of the one-to-many mapping, a session of type MultipointHead
>    SHOULD NOT initiate a Poll Sequence in conjunction with timer value
>    changes.  However, to indicate a change in the packets,
>    MultipointHead session MAY send packets with the P bit set during 
> transition period.
[BB]: If I were an implementer, I would not know what this is saying I 
ought to implement. The spec needs to answer this question: If the head 
changes the packets what happens differently if it sets the P bit vs. if 
it doesn't?

>
>     4.11.  Detection Times
>     Delete "in the calculation" (repetition).
>
> GIM>> Done.
>
>
>     4.13.1.  Reception of BFD Control Packets
>     Some actions seem to be only relevant to PointToPoint sessions,
>     but they are
>     stated for all session types. Specifically: "the transmission of
>     Echo packets,
>     if any, MUST cease." "the Poll Sequence MUST be terminated." "MUST
>     cease the
>     periodic transmission of BFD Control packets" "MUST send periodic
>     BFD Control
>     packets"
>
>     "
>     If bfd.SessionType is PointToPoint, update the Detection Time as
>           described in section 6.8.4 of [RFC5880].  If bfd.SessionType is
>           MultipointTail,
>     "
>     The second sentence above ought to start on a new line as an Else if.
>
> GIM>> Hope I got it right:
>       If bfd.SessionType is PointToPoint, update the Detection Time as
>       described in section 6.8.4 of [RFC5880].
>
>       Else
>
>          If bfd.SessionType is MultipointTail, then update the Detection
>          Time as the product of the last received values of Desired Min
>          TX Interval and Detect Mult, as described in Section 5.11 of
>          this specification.
>
>
>     4.13.2.  Demultiplexing BFD Control Packets
>     "
>        This section is part of the replacement for [RFC5880] section
>     6.8.6,
>        separated for clarity.
>     "
>     Do you mean "This section replaces the sentence: "If the
>     Multipoint (M) bit is
>     nonzero, the packet MUST be discarded." in [RFC5880] section 6.8.6?
>
>     The statements under "If the Multipoint (M) bit is set" are not
>     formatted like
>     the rest of the if-else logic, and I think an Else is missing at
>     the start of
>     the statement after the nested "If".
>
> GIM>> Agree, the paragraph is not structured properly. How about this 
> formating:
>       If the Multipoint (M) bit is set
>
>          If the Your Discriminator field is nonzero, the packet MUST be
>          discarded.
>
>          Select a session as based on source address, My Discriminator
>          and the identity of the multipoint path which the Multipoint
>          BFD Control packet was received.
>
>          If a session is found, and bfd.SessionType is not
>          MultipointTail, the packet MUST be discarded.
>
>          Else
>
>             If a session is not found, a new session of type
>             MultipointTail MAY be created, or the packet MAY be
>             discarded.  This choice is outside the scope of this
>             specification.
>
[BB]: As long as this represents the logic you want, fine. The point is 
that the indentation is the only clue to whether one 'if' is conditional 
on a previous 'if', or not.

HTH

Bob




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/