Re: [bess] Martin Duke's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[Greg Mirsky <[e-mail]>]

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 <
[e-mail]> 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)