Multicast VPN Fast Upstream Failover
draft-ietf-bess-mvpn-fast-failover-15

[Ballot comment]
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.

[Ballot comment]
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 ;-)

[Ballot comment]
[[ 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

[Ballot comment]
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.

[Ballot comment]
— 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).

[Ballot comment]
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.

[Ballot comment]
Thank you for the work put into this document.

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 ;-)

[Ballot discuss]
(1) This document describes several methods to determine the status of a
tunnel (in §3), none of which "provide a "fast failover" solution when used
alone, but can be used together with the mechanism described in Section 4"
(§1).  §3 also says this:

  An implementation may support any combination of the methods
  described in this section and provide a network operator with control
  to choose which one to use in the particular deployment.

While §3.1 is clear in the fact that it is not a requirement for all
downstream PEs to use the same mechanism, there are no guidelines to aid the
operator to chose which mechanism to use.  Some cases may be obvious (e.g.
§3.1.3 applies to tunnels of a specific type), but others are not.  I would
like to see deployment considerations related to the advantages/disadvantages
that each method may have in specific situations (including their possible
combination).


(2) The BFD Discriminator Attribute has a very narrow application in this
document when compared to the potential other uses given the extensibility
possibilities related to bootstrapping BFD.  I have serious concerns about
the attribute being defined in this document, amongst a series of other
mechanisms.

(2a) The tunnel can be monitored without the new BGP Attribute (assuming
proper configuration of course).  Why is that option is not even mentioned in
the document? 

In fact, the document recommends deleting the BFD session if the Attribute is
not present.  Why is that recommendation in place, and what are the cases when
it can not be followed?


(2b) The fact that BFD monitoring can be achieved without the new attribute
makes me think that the bootstrapping of BFD using BGP would be better served
in a document produced by the BFD WG.  One of the editors has expressed the
same opinion [1] [2].  Has a discussion taken place in the BFD WG (or at least
with the Chairs) about this work?  Why was it not taken up there?


[1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/T1jVpgyXuPatTpuD_wA0JC3CT1c/
[2] https://tools.ietf.org/wg/bess/minutes?item=minutes-96-bess.html

[Ballot comment]
(0) I support Ben's DISCUSS.


(1) This document (currently) specifies a new BGP attribute, but I couldn't
find any discussion about it in the idr mailing list.  Has idr been given the
opportunity to review?


(2) s/is an OPTIONAL procedure/is an optional procedure
This is not a normative statement to require capitalization.


(3) "VRF Route Import BGP attribute" is mentioned twice (§3 and §5), but it is
not an attribute; it is an extended community (rfc6514).


(4) §3.1.1: "similar to BGP next-hop tracking"  Is this specified somewhere? 
I don't remember seeing a specification for next-hop tracking, but do know
that implementations do it -- in an implementation-specific way.  Please add a
little more text about what is meant/expected.


(5) §3.1.1: "If BGP next-hop tracking is done...and the root
address...[is]...the same as the next-hop address...then checking...whether
the tunnel root is reachable, will be unnecessary duplication...."  I guess
this means that the existing next-hop tracking functionality can be used and
that it doesn't have to be function-specific (root vs next-hop).  This
paragraph seems to assume a specific implementation -- but again, given that
next-hop tracking implementations are internal then this paragraph doesn't
make much sense to me.


(6) The "reachability condition" is mentioned in §3.1.1/§3.1.3/§3.1.4.  Does
this mean that that root tracking (§3.1.1) should be used with the other
mechanisms?  The specific text says that "the downstream PE can immediately
update its UMH when the reachability condition changes", giving the impression
that the combination is possible but not required.

Note that §4.3 is titled "Reachability Determination", which I hoped would
shed more light, but all it does is point back to §3.1.


(7) §3.1.2: What is the "last-hop link" of the tunnel?  Is it the physical
link, or the virtual hop from the previous waypoint? 


(8) §3.1.2 mentions that "careful consideration and coordination" is needed
when using other mechanisms such as rfc4090 "because uncorrelated timers might
cause unnecessary switchovers and destabilize the network."  What are the
associated timers related to the mechanisms in this section?


(9) §3.1.3:

  When using this method and if the signaling state for a P2MP TE LSP
  is removed (e.g., if the ingress of the P2MP TE LSP sends a PathTear
  message) or the P2MP TE LSP changes state from Up to Down as
  determined by procedures in [RFC4875], the status of the
  corresponding P-tunnel MUST be re-evaluated.  If the P-tunnel
  transitions from Up to Down state, the Upstream PE that is the
  ingress of the P-tunnel MUST NOT be considered a valid UMH.

These two sentences are redundant.  It seems to me that they could be
replaced by:

  When using this method and if the signaling state for a P2MP TE LSP
  is removed (e.g., if the ingress of the P2MP TE LSP sends a PathTear
  message) or the P2MP TE LSP changes state from Up to Down as
  determined by procedures in [RFC4875], the Upstream PE that is the
  ingress of the P-tunnel MUST NOT be considered a valid UMH.


(10) §3.1.4: "An Upstream PE SHOULD be removed from the UMH candidate
list...if...the upstream one-hop branch of the tunnel from P to PE cannot be
built."  When is it ok to not remove the PE?  IOW, why is this action not
required?


(11) [nit] s/mechanism to execute its actions/mechanism execute its actions


(12) §3.1.5 says that "where this mechanism is used in conjunction with the
method described in Section 5...downstream PEs can compare reception on the
two P-tunnels to determine when one of them is down", but §5 says that
"downstream PEs accept traffic from the primary or standby tunnel, based on
the status of the tunnel (based on Section 3)".  IOW, §3.1.5 points at §5 as
providing a way to determine if a tunnel is down, while §5 points back at §3
as the way to determine which tunnel to receive from.  This pointing back and
forth is not a total contradiction, but it needs to be clarified.


(13) §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]."

There cannot be a Normative action specified for a node that "does not
recognize...this attribute" because, by definition, it can't be assumed that
it is aware of this specification.  In this case, it is not necessary to say
anything about unrecognized attributes because that is already specified in
rfc4271.

For the "configured not to support this attribute" case, it should be pointed
out that the node should operate as if the attribute was unrecognized.

Suggestion>
  An implementation that is configured not to support this attribute MUST
  follow the procedures defined in Section 5 of [RFC4271] as if the attribute
  was unrecognized.


(14) [nit] s/BFD Mode field is the one octet long./The BFD Mode field is one
octet long.


(15) §3.1.6: "The BFD Discriminator attribute MUST be considered malformed if
its length is not a non-zero multiple of four."  Ok, except that the
specification of the attribute doesn't mention the length (only the length of
the TLVs).  Please specify the length and any considerations related to the
Extended Length bit.  Also, given that this is a new attribute, with an
unspecified potential number of TLVs, and that the length is apparently
unbounded, all leading to the potential need for extended messages, please
specify how to handle peers that cannot accommodate more than 4k octet
messages (rfc8654).


(16) §3.1.6.1: "MUST set the IP destination address of the inner IP header to
one of the internal loopback addresses..."  Where do these addresses come
from?  How does the Upstream PE figure out which one to use?  At least please
include a reference to where that is explained.


(17) §3.1.6.1: "MUST use its IP address as the source IP address"  Which
address?  Please be specific.


(18) §3.1.6.2: If the IP address doesn't map correctly at the downstream PE
(for example, a different local address is used that doesn't correspond to the
information in the PMSI attribute), what action should it take?  Can the
tunnel still be monitored?


(19) §3.1.6.2: "SHOULD NOT switch the traffic to the Standby Upstream PE" 
When is it ok to do it?  IOW, why is this action recommended, and not
required.


(20) §3.1.7: "set the bfd.LocalDiag of the P2MP BFD session to Concatenated
Path Down and/or Reverse Concatenated Path Down"    Which one?  bfd.LocalDiag
carries a single value.


(21) §3.1.7: "...it is desired for the downstream PEs to switch to a backup
Upstream PE.  To achieve that...it SHOULD set the bfd.LocalDiag..."  If not
set, then the objective won't be achieved.  When is it ok to not set the
bfd.LocalDiag to indicate the concatenated failure?


(22) §4: "Such behavior is referred to as "revertive" behavior and MUST be
supported."  The text around this sentence seems to indicate that the
revertive behavior is the default, is that the intent?  Or if the intent for
it just to be supported (as written)?  Please be clear.


(23) §4.1: "...routes that carry the "Standby PE" BGP Community MUST have the
LOCAL_PREF attribute set to zero."  What should a receiver do if the
LOCAL_PREF is not zero?


(24) §4.1: In the last paragraph of this section, if I follow correctly, the
text talks about the case where the standby becomes the primary and the
updated advertisement doesn't have the Standby PE community.  If that is
correct, then s/ presence/absence of the Standby PE BGP Community/ absence of
the Standby PE BGP Community

Also, the last sentence says that the "LOCAL_PREF attribute MUST be set to
zero".  If the community is not present, how can a receiver enforce this? 
What action should it take if the LOCAL_PREF has a different value?


(25) §4.3: "other mechanisms MAY be used"  s/MAY/may  This is just a
statement of fact.


(26) §4.4.2: "MUST try to locate"  To try is not an action that can be
normatively enforced.  Also, I don't think that using "MUST" here adds value
since the normative action is in the next sentence ("MUST perform as
follows"). s/MUST/must


(27) s/"hot root standby" mode is used (Section 4)/"hot root standby" mode is
used (Section 5)


(28) §7.3: s/sub-TLV/TLV/g  The attribute includes TLVs, not sub-TLVs.

[Ballot comment]
- 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"

[Ballot discuss]
Let's talk about what the requirements are for consistency across PEs in
the algorithm for selecting the Primary Upstream PE.  Section 4 notes
that "all the PEs of that MVPN [are required] to follow the same UMH
selection procedure", but leaves the option of non-revertive behavior as
something that "MAY also be supported by an implementation", without
requirement for consistency across all PEs.  It seems to me that if some
PEs use non-revertive behavior and others do not, then they will
disagree as to which PE is the Primary (or active) PE in some cases,
which seems to conflict with the initial guidance that all PEs needed to
pick the same one.  Is it perhaps that the PEs need to agree on which PE
is to be advertised as Primary but not necessarily to actually be using
that one for traffic?  Or am I missing something?

[Ballot comment]
Section 1

  Section 3 describes local procedures allowing an egress PE (a PE
  connected to a receiver site) to take into account the status of
  P-tunnels to determine the Upstream Multicast Hop (UMH) for a given
  (C-S, C-G).  [...]

Does it also apply to (C-*, C-G)?  (I'll just mention it once, but the
handling seems to be somewhat inconsistent throughout the document, with
(C-*,C-G) getting mentioned sometimes but not always, and no pattern
obvious to me for when it is or is not included.  I think I see some
instances where (C-*, C-G) does not make sense, so it would probably not
be a universal replacement.)

  Section 5 describes a "hot leaf standby" mechanism that can be used
  to improve failover time in MVPN.  The approach combines mechanisms
  defined in Section 3 and Section 4 has similarities with the solution
  described in [RFC7431] to improve failover times when PIM routing is
  used in a network given some topology and metric constraints.

nit: grammar issue around "has similarities with" (maybe needs a leading
"and"?)

  VPNs.  An operator would enable these mechanisms using a method
  discussed in Section 3 in combination with the redundancy provided by
  a standby PE connected to the source of the multicast flow, and it is
  assumed that all PEs in the network would support these mechanisms
  for the procedures to work.  In the case that a BGP implementation

Is it a matter of "the procedure will not work at all unless all PEs in
the network support it", or "only the PEs that support it will get the
benefits of it"?  [The next sentence suggests an anwer...]

Section 3

  Section 9.1.1 of [RFC6513] are applicable when using I-PMSI
  P-tunnels.  That document is a foundation for this document, and its
  processes all apply here.  Section 9.1.1 mandates the use of specific
  procedures for sending intra-AS I-PMSI A-D Routes.

(nit) the second "Section 9.1.1" is also referring to RFC 6513, not this
document, which would be the default interpretation of a bare section
reference.

(not-nit) The referenced procedure seems to be about processing, not
sending, intra-AS I-PMSI A-D routes.  Am I misreading something?

Section 3.1

  Different factors can be considered to determine the "status" of a
  P-tunnel and are described in the following sub-sections.  The
  optional procedures described in this section also handle the case
  the downstream PEs do not all apply the same rules to define what the
  status of a P-tunnel is (please see Section 6), and some of them will
  produce a result that may be different for different downstream PEs.

nit: I think it's better to put a word like "where" in "the case the
downtream PEs".

Section 3.1.3

  corresponding P-tunnel MUST be re-evaluated.  If the P-tunnel
  transitions from Up to Down state, the Upstream PE that is the
  ingress of the P-tunnel MUST NOT be considered a valid UMH.

(nit?) I'm not sure how much precedent there is for using "valid" in
this context -- IIUC the previous discussion of this process referred
only to whether a PE is a candidate for being the UMH.

Section 3.1.5

  When such a procedure is used, in the context where fast restoration
  mechanisms are used for the P-tunnels, a configurable timer MUST be
  set on the downstream PE to wait before updating the UMH, to let the
  P-tunnel restoration mechanism to execute its actions.  An
  implementation SHOULD use three seconds as the default value for this
  timer.

How does this interact with the value of the maximum inter-packet time?
Suppose that I know to expect at least one packet every ten seconds.  Do
I wait ten seconds after receiving the last packet and then another
three seconds, before engaging in an UMH change?

  In cases where this mechanism is used in conjunction with the method
  described in Section 5, no prior knowledge of the rate of the
  multicast streams is required; downstream PEs can compare reception
  on the two P-tunnels to determine when one of them is down.

This feels a little underspecified; is there a reference or more
guidance that we could give about turning a stream of received packets
on one tunnel into a maximum inter-packet time on another tunnel,
supposedly carrying the same traffic?

Section 3.1.6

      *  one octet-long field of TLV's Type value (Section 7.3)

      *  one octet-long field of the length of the Value field in octets

      *  variable length Value field.

      The length of a TLV MUST be multiple of four octets.

I assume this is the total length, not the value in the length field?

  The BFD Discriminator attribute MUST be considered malformed if its
  length is not a non-zero multiple of four.  If the attribute
  considered malformed, the UPDATE message SHALL be handled using the
  approach of Attribute Discard per [RFC7606].

nit: s/attribute considered/attribute is considered/

Section 3.1.6.1

  o  MUST periodically transmit BFD Control packets over the x-PMSI
      P-tunnel after the P-tunnel is considered established.  Note that
      the methods to declare a P-tunnel has been established are outside
      the scope of this specification.

Is there a good reference for how to choose the period of transmission?

  If the tracking of the P-tunnel by using a P2MP BFD session is
  enabled after the x-PMSI A-D Route has been already advertised, the
  x-PMSI A-D Route MUST be re-sent with precisely the same attributes
  as before and the BFD Discriminator attribute included.

Pedantically, it seems like "precisely the same attributes as before"
is incompatible with adding the BFD Discriminator attribute.  Phrasing
that discusses "the only change between the previous advertisement and
the new advertisement" would not suffer from such a potential issue.
(And similarly for when the BFD Discriminator attribute is to be
removed, a couple paragraphs later.)

Section 3.1.6.2

  o  MUST use the source IP address of the BFD Control packet, the
      value of the BFD Discriminator field, and the x-PMSI Tunnel
      Identifier [RFC6514] the BFD Control packet was received to
      properly demultiplex BFD sessions.

nit: missing word around "the BFD Control packet was received" (maybe
"received on/in"?).

  According to [RFC8562], if the downstream PE receives Down or
  AdminDown in the State field of the BFD Control packet or associated
  with the BFD session Detection Timer expires, the BFD session is

nit: "the BFD Detection Timer associated with the BFD session expires"

  PE, while others are considered as Standby Upstream PEs.  In such a
  scenario, when the P-tunnel is considered down, the downstream PE MAY
  initiate a switchover of the traffic from the Primary Upstream PE to
  the Standby Upstream PE only if the Standby Upstream PE is deemed
  available.

I'm not sure that we've defined what it means for an Upstream PE to be
deemed "available', yet.  I guess it's possible that there is not an
established P-Tunnel between the (selected) Standby Upstream PE and the
donstream PE, so just using the Up/Down/not-known-to-be-Down status of
that P-tunnel is not an option...

  If the downstream PE's P-tunnel is already established when the
  downstream PE receives the new x-PMSI A-D Route with BFD
  Discriminator attribute, the downstream PE MUST associate the value
  of BFD Discriminator field with the P-tunnel and follow procedures
  listed above in this section if and only if the x-PMSI A-D Route was
  properly processed as per [RFC6514], and the BFD Discriminator
  attribute was validated.

We did not discuss any validation of the BFD Discriminator attribute in
§3.1.6; what procedures would this process entail?

Section 4

  The procedures described below are limited to the case where the site
  that contains C-S is connected to two or more PEs, though, to
  simplify the description, the case of dual-homing is described.  The

I suggest giving at least some considerations to how to choose between
multiple standby Upstream PEs when there are more than one available.

  procedures require all the PEs of that MVPN to follow the same UMH
  selection procedure, as specified in [RFC6513], whether the PE
  selected based on its IP address, hashing algorithm described in
  section 5.1.3 of [RFC6513], or Installed UMH Route.  The procedures

I assume that how the PEs agree on which procedure is in use does not
involve something being advertised in-band, and is out of scope for this
document.  But please say so!

  assume that if a site of a given MVPN that contains C-S is dual-homed
  to two PEs, then all the other sites of that MVPN would have two
  unicast VPN routes (VPN-IPv4 or VPN-IPv6) to C-S, each with its RD.

nit: s/its RD/its own RD/
Also, please confirm that the unicast routes are *to* C-S, vs *from* it.

Section 4.1

  o  the NLRI is constructed as the C-multicast route with an RT that
      identifies the Primary Upstream PE, except that the RD is the same
      as if the C-multicast route was built using the Standby Upstream
      PE as the UMH (it will carry the RD associated to the unicast VPN
      route advertised by the Standby Upstream PE for S and a Route
      Target derived from the Standby Upstream PE's UMH route's VRF RT
      Import EC);

This part is a bit confusing to me, since the first part says that the
RT identifies the Primary Upstream PE, but the second part says that the
RT is derived from the Standy Upstream PE's [stuff].  But I'm happy to
trust you that the [stuff] makes it correct!

Section 4.2

      when the PE determines (the use of the particular method to detect
      the failure is outside the scope of this document) that C-S is not
      reachable through some other PE, the PE SHOULD install VRF PIM

It seems like a forward reference to §4.3 might be helpful.

  Section 9.3.2 of [RFC6514], describes the procedures of sending a
  Source-Active A-D Route as a result of receiving the C-multicast
  route.  These procedures MUST be followed for both the normal and
  Standby C-multicast routes.

There is no section 9.3.2 in RFC 6514.  There is a 9.2.3 that looks
perhaps plausible, though the string "Source-Active" does not appear in
it.

Section 4.4.2

  Source AS carried in the C-multicast route.  If the match is found,
  and the C-multicast route carries the Standby PE BGP Community, then
  the ASBR MUST perform as follows:

(I assume that there is room for local policy to modify this "MUST",
e.g., if needed to protect against some form of attack ... perhaps it
even goes without saying.)

Section 5

  o  Upstream PEs use the "hot standby" optional behavior and thus will
      forward traffic for a given multicast state as soon as they have
      whether a (primary) BGP C-multicast route or a Standby BGP
      C-multicast route for that state (or both)

nit: the grammar is a bit weird here, after "as soon as they have"; I'm
not confident that I could make an accurate suggestion for a fix.

Section 6

I could almost see the discussion of duplicate packets as being a
subsection of the security considerations, though I don't mind leaving
it as-is.

Section 8

We could perhaps make some pro forma note that the BFD Discriminator
attribute, like all BGP attributes, typically does not benefit from
cryptographic integrity protection and thus could be spoofed so as to be
different than what is actually used by the multipoint BFD head.  That
said, I'm willing to let this fall under the incorporated-by-reference
BGP security considerations.

Is it worth noting that operating in "hot" standby mode will increase
the general level of traffic on the VPN and thus susceptibility to DoS?

  This document uses P2MP BFD, as defined in [RFC8562], which, in turn,
  is based on [RFC5880].  Security considerations relevant to each
  protocol are discussed in the respective protocol specifications.  An
  implementation that supports this specification MUST use a mechanism
  to control the maximum number of P2MP BFD sessions that can be active
  at the same time.

What is the objective that this control is designed to achieve?  I can
"control the maximum number of sessions" by asserting the maximum number
to be an absurdly large value, but I don't think that would meet the
spirit of this requirement (it does meet the letter of the requirement).

  The methods described in Section 3.1 may produce false-negative state
  changes that can be the trigger for an unnecessary convergence in the
  control plane, ultimately negatively impacting the multicast service
  provided by the VPN.  An operator is expected to consider the network
  environment and use available controls of the mechanism used to
  determine the status of a P-tunnel.

We mentioned earlier (e.g., in §3.1) that similar negative effects can
occur when resiliency mechanisms at different layers interact; that
might be worth repeating here.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bess-mvpn-fast-failover-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the Border Gateway Protocol (BGP) Well-known Communities registry located at:

a new registration will be made as follows:

https://www.iana.org/assignments/bgp-well-known-communities/

Attribute Value: [ TBD-at-Registration ]
Attribute: Standby PE
Reference: [ RFC-to-be ]

Second, in the BGP Path Attributes registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

a new registration will be made as follows:

Value: [ TBD-at-Registration ]
Code: BFD Discriminator
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the BFD Mode registry. The new registry is to be created on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

The registration policies for the new registry (RFC8126) are:

+-----------+-------------------------+
| Value | Policy |
+-----------+-------------------------+
| 0- 175 | IETF Review |
| 176 - 249 | First Come First Served |
| 250 - 254 | Experimental Use |
| 255 | IETF Review |
+-----------+-------------------------+

There are initial registrations in the new registry as follows:

+-----------+------------------+---------------+
| Value | Description | Reference |
+-----------+------------------+---------------+
| 0 | Reserved | [ RFC-to-be ] |
| 1 | P2MP BFD Session | [ RFC-to-be ] |
| 2- 175 | Unassigned | [ RFC-to-be ] |
| 176 - 249 | Unassigned | [ RFC-to-be ] |
| 250 - 254 | Experimental Use | [ RFC-to-be ] |
| 255 | Reserved | [ RFC-to-be ] |
+-----------+------------------+---------------+

Fourth, a new registry is to be created called the BFD Discriminator Optional Sub-TLV Type registry. The new registry is to be created on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

The registration policies for the new registry (RFC8126) are:

+-----------+-------------------------+
| Value | Policy |
+-----------+-------------------------+
| 0- 175 | IETF Review |
| 176 - 249 | First Come First Served |
| 250 - 254 | Experimental Use |
| 255 | IETF Review |
+-----------+-------------------------+

There are initial registrations in the new registry as follows:

+-----------+------------------+---------------+
| Value | Description | Reference |
+-----------+------------------+---------------+
| 0 | Reserved | [ RFC-to-be ] |
| 1- 175 | Unassigned | [ RFC-to-be ] |
| 176 - 249 | Unassigned | [ RFC-to-be ] |
| 250 - 254 | Experimental Use | [ RFC-to-be ] |
| 255 | Reserved | [ RFC-to-be ] |
+-----------+------------------+---------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.
Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-19):

From: The IESG
To: IETF-Announce
CC: bess@ietf.org, bess-chairs@ietf.org, martin.vigoureux@nokia.com, slitkows.ietf@gmail.com, draft-ietf-bess-mvpn-fast-failover@ietf.org, Stephane Litkowski
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Multicast VPN Fast Upstream Failover) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Multicast VPN Fast Upstream Failover'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines multicast VPN extensions and procedures that
  allow fast failover for upstream failures, by allowing downstream PEs
  to take into account the status of Provider-Tunnels (P-tunnels) when
  selecting the Upstream PE for a VPN multicast flow, and extending BGP
  MVPN routing so that a C-multicast route can be advertised toward a
  Standby Upstream PE.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2696/
  https://datatracker.ietf.org/ipr/2697/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended to be Standard Track. It defines new procedures and additional protocol extensions which perfectly fits with Standard Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures.


Working Group Summary:

There was no particular controversy on this draft but multiple enhancements have been added over time by various contributors.
The document is in the WG for a while and the initial authors/editors were not maintaining it anymore. We had to appoint a new editor to close the work as the WG was interested to finish the work.


Document Quality:

We are not aware of any implementation. Documents has been reviewed by some key people in the WG.

Personnel:

Stephane Litkowski is the document shepherd and Martin Vigoureux is the responsible AD.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has done a deep review and provided a long list of comments that have been addressed by the editor.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concern

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Some of the contributors are retired now, and were not able to reply to the IPR poll.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Two IPRs are disclosed. No particular discussion on the IPRs.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
We have a good support from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
no

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
No

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/a

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
IANA considerations have been reviewed and comments have been addressed.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
n/a

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
none

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
n/a

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document is intended to be Standard Track. It defines new procedures and additional protocol extensions which perfectly fits with Standard Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures.


Working Group Summary:

There was no particular controversy on this draft but multiple enhancements have been added over time by various contributors.
The document is in the WG for a while and the initial authors/editors were not maintaining it anymore. We had to appoint a new editor to close the work as the WG was interested to finish the work.


Document Quality:

We are not aware of any implementation. Documents has been reviewed by some key people in the WG.

Personnel:

Stephane Litkowski is the document shepherd and Martin Vigoureux is the responsible AD.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has done a deep review and provided a long list of comments that have been addressed by the editor.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concern

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Some of the contributors are retired now, and were not able to reply to the IPR poll.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Two IPRs are disclosed. No particular discussion on the IPRs.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
We have a good support from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
no

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
No

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/a

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
IANA considerations have been reviewed and comments have been addressed.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
n/a

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
none

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
n/a