Multicast VPN Fast Upstream Failover
RFC 9026

Note: This ballot was opened for revision 13 and is now closed.

Martin Vigoureux Yes

Alvaro Retana (was Discuss) No Objection

Comment (2021-01-21)
No email
send info
[Thanks for addressing my DISCUSS.]

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-12-23 for -14)
Thank you for addressing my discuss (and comment!) points.

Given what I have read so far in Alvaro's ballot thread, I had expected
the Reserved field to be removed from the BFD Discriminator attribute
format, but I will let that play out in Alvaro's ballot thread.

Erik Kline No Objection

Comment (2020-12-16 for -13)
No email
send info
[[ comments ]]

[ section 3.1.6.1 ]

* I too am not happy about seeing ::ffff:127.0.0.0/104 in the wild, but
  I personally think the community should have followed through on any of
  the various 1::/{32,48,64} proposals that could have resulted in IANA
  designating a loopback prefix.

  Maybe it's time to try taking up that work again.

  /me makes a note to self

Martin Duke No Objection

Comment (2020-12-15 for -13)
- This document should expand acronyms on first use, particularly those in the Abstract.

- 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.

- The last paragraph of S1 describes "protection for multicast services". Can you elaborate what this is protection from? The latency associated with tunnel failure?

- 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.

- Sec 5. I think you should delete the word "whether"

Murray Kucherawy No Objection

Comment (2020-12-16 for -13)
I concur with Barry's point about the definitions in Section 2.2.

I can't quite parse the first sentence of Section 3.1.1.  Maybe this will help:

OLD:

   A condition to consider that the status of a P-tunnel is Up is that
   the root of the tunnel, as determined in the x-PMSI Tunnel attribute,
   is reachable through unicast routing tables.

NEW:

   When determining whether the status of a P-tunnel is Up, a condition
   to consider is whether the root of the tunnel, as determined in the
   x-PMSI Tunnel attribute, is reachable through unicast routing tables.

Section 3.1.2 has a similar concern.

Why is that a SHOULD and not a MUST in Section 3.1.6.1?  Same question about 3.1.6.2, and the ones in 4.2.  Or, if they are correctly SHOULDs, you might consider giving some guidance to the reader about when one might go about deviating from the advice given, since SHOULD offers a choice.

I think in Sections 7.2 and 7.3, you don't need "this document" references for unassigned things.

Roman Danyliw No Objection

Comment (2020-12-16 for -13)
Thank you to Daniel Migault for the SECDIR review

I support Ben and Alvaro's DISCUSS positions.

One editorial nit from Section 3.1.6: 

An implementation that does not recognize
   or is configured not to support this attribute MUST follow procedures
   defined for optional transitive path attributes in Section 5 of
   [RFC4271]. 

It seems odd to be specifying normative language for implementations that do not/will not understand this specification.  I appreciate that this MUST is coming from RFC4271.

Éric Vyncke (was Abstain) No Objection

Comment (2020-12-21 for -13)
Thank you for the work put into this document and for addressing my previous comments. My previous position is kept below ***ONLY FOR ARCHIVE*** as the authors have proposed text to fix those issues.

-éric

===FOR ARCHIVE ONLY===

I have balloted ABSTAIN in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others." because of the use outside of a node of the IPv4-mapped IPv6 addresses in section 3.1.6.1. A reply on this topic will be welcome.

Stéphane in his doc shepherd's write up states that no implementation is known for a document born in 2008... Does the IETF really want to have this on the proposed standards track ?

Please find below my ABSTAIN point, some non-blocking COMMENT points (but replies would be appreciated), and one nits.

I hope that this helps to improve the document,

Regards,

-éric

== ABSTAIN ==
-- Section 3.1.6.1 --
I appreciate that the BFD WG relies on "::ffff:127.0.0.0/104" but those IPv4-mapped IPv6 addresses are assumed to never leave a node and should never be transmitted over the Internet (see https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my ABSTAIN. As the inner packet is sent over a tunnel, why not using the a link-local address or the ff02::1 link-local multicast group ?


== COMMENTS ==

-- Section 2.3 --
The use of "upstream" and "Upstream" could be confusing... The latter could have been "Upstream PE/ABSR" (often used later in the document) or "ingress node" 

-- Section 3.1.6 --
Could the "BFD Discreminator" attribute be used for other purpose than this document? If so, then why not specifying it in *another* document?

Should this document clearly state that it does not define any TLV ?

== NITS ==

As I am probably not the only reader have difficulties to remember RFC contents by their number, may I suggest to prefix the RFC numbers with their titles ? Esp in the introduction ;-)

(Barry Leiba; former steering group member) No Objection

No Objection (2020-12-16 for -13)
— Section 1 —

   The procedures described in this document are optional to enable an
   operator to provide protection for multicast services in BGP/MPLS IP
   VPNs.  An operator would enable these mechanisms using a method
   discussed in Section 3 in combination with the redundancy provided by

It’s a very small point, but I think it’s just a little harder to follow than necessary because of two uses of “enable” with different senses — it’s easy to read the first in the same sense as the second, “optional to enable” (rather than “to enable an operator to...”).  I suggest changing the first to “allow”, and maybe also change it slightly, so: “are optional, and allow an operator to...”.

— Section 2.2 —
It’s usually not a good idea to have different definitions for things such as “upstream” and “Upstream”, for one reason because they can’t be distinguished if they begin a sentence (where they’ll both appear as “Upstream”), and for another because it’s easy to inadvertently write the wrong one and not catch it.  I checked, and I don’t see any case of the first in this document (where “Upstream” appears at the beginning of the second bullet in Section 5 it seems to be clear because of “downstream” in the other bullets), but you need to be careful not to introduce that ambiguity during the editing process.  It would be good for the AD to include an RFC Editor note to that effect, so they are alerted to this situation and to avoid beginning any sentences with “Upstream”.  And the authors should be sure to carefully check every instance of the word during AUTH48 (it would be good for the RFC Editor to include a reminder of that in the AUTH48 message).

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -13)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -13)
No email
send info