Hi Martin, thank you for your review and comments. Please find my answers, notes, and the proposed updates below under the GIM>> tag.
Regards, Greg On Tue, Dec 15, 2020 at 12:08 PM Martin Duke via Datatracker < [email protected]> wrote: > Martin Duke has entered the following ballot position for > draft-ietf-bess-mvpn-fast-failover-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - This document should expand acronyms on first use, particularly those in > the > Abstract. > GIM>> Thank you for pointing to this. The updated Abstract is now as follows: This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow. The fast failover is enabled by using RFC 8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks and the new BGP Attribute - BFD Discriminator. Also, the document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN routing so that a C-multicast route can be advertised toward a Standby Upstream PE. > > > - Similarly, a couple of new paragraphs in Section 1 would be a useful boot > camp for concepts like PEs, P-Multicast, C-Multicast, BFD, RT, etc. I spent > some time in RFC 6513 and I'm still pretty unclear on these. > GIM>>I agree that the document relies heavily on RFCs 6513 and 6514. We've stressed that in the first paragraph of Section 1: It is assumed that the reader is familiar with the workings of multicast MPLS/BGP IP VPNs as described in [RFC6513] and [RFC6514]. And in the RtgDir review we also received this comment: This document is fairly easy to read, but demands a thorough understanding of RFCs 6513 and 6514. That is not unreasonable. Adding text that explains some of the concepts of VPN and MPVN may be challenging because it might be difficult to determine how much information is sufficient for a reader and not to overload the document with the quotes from RFCs 4364, 6513, and 6514 (also BFD-related RFCs 5880 and 8562). > > - The last paragraph of S1 describes "protection for multicast services". > Can > you elaborate what this is protection from? The latency associated with > tunnel > failure? > GIM>> Strictly speaking, mechanisms described and defined in the document expedite the convergence of the MVPN control plane when compared with the regular convergence time of the BGP-based VPN control plane. That, in turn, enables a faster switchover in the data plane. As the result, using the methods described, an operator minimizes the packet loss in the protected multicast service. Hope that clarifies the context of "protection for multicast services" in this document. > > - In Section 3.1.6, please clarify if the length field of the TLV must be a > multiple of 4 octets, or the entire TLV (including type and length) should > be a > multiple of 4. From context, I suspect the latter is true, but it could > easily > be misread otherwise. > GIM>> While addressing Ben's comment I've updated that part of the text. Please let me know if the updated version makes it clearer: * Type - a one-octet-long field that characterizes the interpretation of the Value field (Section 7.3) * Length - a one-octet-long field equal to the length of the Value field in octets * Value - a variable-length field. The length of a TLV as a whole MUST be multiple of four octets. > > - Sec 5. I think you should delete the word "whether" > GIM>> I agree that it is not used correctly in that sentence and that removing it seems like the simplest way fixing it. I've updated the text while addressing another comment. Please let me know if the version below reads as an improvement: o Upstream PEs use the "hot standby" optional behavior and thus will start forwarding traffic for a given multicast state after they have a (primary) BGP C-multicast route or a Standby BGP C-multicast route for that state (or both)
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
