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.