Thanks for the replies. They are satisfactory. On Wed, Dec 16, 2020 at 5:00 PM Greg Mirsky <gregimir...@gmail.com> wrote:
> 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 < > nore...@ietf.org> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
