Early Review of draft-ietf-bess-bgp-multicast-05
review-ietf-bess-bgp-multicast-05-genart-early-halpern-2023-10-23-00

This is a requested genart early review of

draft-ietf-bess-bgp-multicast-05

Prepared on 23-Oct-2023

Summary: This draft is not ready, having a number of issues that need to be
addressed.

I presume this draft will be socialized with the PIM and IDR working groups
before completion (or maybe it already has been?)

Major:
    While I appreciate the effort to give an overview of the operation before
    providing the specification, the actual text is almost impossible to
    follow.   At a guess, the authors have a coherent view of what happens, and
    have then written down each "interesting" piece.   This does not give the
    reader clarity. As a first step, before giving the overview, all the
    terminology needs to be defined.  Including such things as the fact that
    MCAST-TREE NLRI is a general holder, within which there are a number of
    different NLRI (which is finally explained in section 2, after the reader
    is thoroughly confused.)  All terms and abbreviations should be defined or,
    when they are from other documents, expanded with a citation so the reader
    knows where to look for the term.  (I did figure out what FHR and LHR were,
    but the draft did not help me do so.) Secondly, the extensive use of
    construction of the form ~this use of construct A is just like the use in
    document B except...~ is very confusing.  The reader is left without a
    coherent description of how this protocol works, exactly which pieces from
    the other document must be followed, and exactly how the changes are to be
    applied. Third, if the intention of the introductory material is to provide
    a perspective on, but not duplicative specification of, the material in
    section 2.2, then each overview should have forward references explaining
    where the detailed procedures can be found.  If material in the overview is
    intended to be the normative specification of the operation (as for example
    when and which rotue communities are to be used, and apparently all of
    section 1.2.1.1) then normative language is needed.  It is quite hard to
    exgtract from these sections the required procedures.

    I also note that ID-Nits ha a lot of complaints.  I will not repeat them,
    but they need to be dealt with. (For example, the addresses used in various
    examples are not example addresses.  They should be.)

    Scaling needs to be better addressed.  While I understand the use of RT
    constraints helps the avoidance of overloading the leaves of the tree, it
    appears that any network using route reflectors is likely to have state
    about every sender of every multicast group in every rotue reflector.  It
    may be that this is acceptable.  But it should be called out explicitly.

Section 2.2.1 sates that source advertisement will be triggered only by sources
sending multicast traffic.  And will expire based on time.  Except that the
network has no idea what the suitable time interval is for a given multicast
group.  Some groups will have long inter-packet intervals, while some will be
short and some will be quite variable.  Also, some groups will have the
property that the senders will know who they are before sending, and receivers
may even want to join before the senders are active.  If the working group
wishes to exclude such use cases, then the document should be explicit about
what use cases it is covering.

Moderate:
Additional explanation is needed in section 1.2.1.2.  This section describes
how to set up a shared tree for an ANY-Source Multicast Group.  Unlike the
earlier discussion of advertising sources with a route target community to
restrict distribution, this section explicitly says that the sources sending to
the ASM Group are advertised in BGP without the restricting community.  I
presume there is some other assumed aspect that restrits the information so it
is only received by the Rendezvous points for the shared tree.  But I can not
see how this is achieved.  Please add explanation of why this approach does not
flood the whole domain with information it does not want or need.

The last paragraph (short) of section 1.2.1.2 gives a vague description of
certain cases.  Presuming it is described in more detail later, a forward
reference would be extremely helpful.

Section 1.2.1.3 has very confusing use of ingress and egress PE.  I would have
assumed ingress and egress were in terms of the direction of traffic flow (from
traffic sources to interested receivers).  But the usage in both paragraphs
seems to be exactly the opposite.

Section 1.2.3 refers to establishing information via an IGP ("IGP neighbor
discovery").  Except that the earlier descriptions indicate that the deployment
case here is for a pure BGP domain, with no IGP.  (Otherwise, there would need
to be extensive procedures as to how the multicasts traverse regions that use
the IGP instead of BGP.)

Section 1.2.4 discusses handling when multiple itnerfaces connect two peers and
one is sending multicast traffic to be received by the other.  THe text seems
to say it just works.  The receivers receives whatever is sent, and the sender
sends on whatever interface it wants to use.  This seems insufficient.  For
example, suppose we have several routers, one upstream router A, with two
downstream LANs, Lan 1 and Lan 2.  Routers B and C are on Lan 1, while routers
C and D are on Lan 2.  And all three of A, B, and C subscribe to receive a
specific multicast.  It appears that A will need to send the multicast on both
Lan 1 and Lan 2, so that B and D receive them.  Which means that C will receive
two copies of the multicast.  And apparently there is no procedure for C to
know this is happening and ignore one of the two interfaces.

Section 1.2.7 discusses the interaction with BGP Classfull transport
(draft-ietf-idr-bgp-ct).  CT is one of two competing experimental approaches
(CAR is the other).  This draft should either discuss interaction with both of
them, or neither.  And if it is going to discuss interaction with experimental
proposals, it should note that at the time of writing, they are experimental.

As an example of the problem of using references to other drafts without
sufficient specificity, section 2.1.4 "The encoding is similar to the same
route in [RFC7441]." does not tell the implementor what the encoding is.  It
tells him to guess.

I presume this draft is intended to work with IPv4 and IPv6.  Examples should
be included using both kinds of addresses.

Section 2.1.7 Topology/IPA Extended Community should include either an
explanation of what this community is for, or a reference to where else in the
document this community is described.