Hi,
I have the following questions/comments:
The procedure described here is an OPTIONAL procedure that consists
of having a downstream PE take into account the status of P-tunnels
rooted at each possible upstream PEs, for including or not including
each given PE in the list of candidate UMHs for a given (C-S,C-G)
state. The result is that, if a P-tunnel is "down" (see
Section 3.1), the PE that is the root of the P-tunnel will not be
considered for UMH selection, which will result in the downstream PE
to failover to the upstream PE which is next in the list of
candidates.
Is it possible that a p2mp tunnel is considered up by some leaves but down by
some other leaves, leaving to them choosing different UMH? In that case,
procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE") of
RFC 6513 must be used. I see that this is actually pointed out later in section
6 - good to have a pointer to it right here.
Additionally, the text in section 3 seems to be more biased on Single Forwarder
Election choosing the UMH with the highest IP address. Section 5 of RFC6513
also describes two other options, hashing or based on "installed UMH route"
(aka unicast-based). It is not clear how the text in this document applies to
hashing based selection, and I don't see how the text applies to unicast-based
selection. Some rewording/clarification are needed here.
For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
considered up if one or more of the P2MP RSVP-TE LSPs, identified by
the P-tunnel Attribute, are in Up state.
Why is "one or more of ..." used in the above text?
There are several occurrences of ((S, G)). I assume they should be changed to
(C-S, C-G).
A PE can be removed from the UMH candidate list for a given ((S, G))
if the P-tunnel for this (S, G) (I or S , depending) is leaf
triggered (PIM, mLDP)
Perhaps either remove the (I or S , depending)or move it to before the "for".
This document defines the format and ways of usingr a new BGP
attribute called the "BGP- BFD attribute".
s/usingr/using/
o MUST use [Ed.note] address as destination IP address when
transmitting BFD control packets;
[Ed.note]?
If tracking of the P-tunnel by using a p2mp BFD session is to be
enabled after the P-tunnel has been already signaled, the the
procedure described above MUST be followed.
What if the tracking is to be enabled before the P-tunnel has been signaled?
The text implies different behavior?
s/the the/then the/
... The dedicated p2mp BFD session MAY monitor the state of
the Standby Upstream PE.
What does the above text mean? Do you mean "A different p2mp BFD session "?
When such a procedure is used, in the context where fast restoration
mechanisms are used for the P-tunnels, leaf PEs should be configured
to wait before updating the UMH, to let the P-tunnel restoration
mechanism happen. A configurable timer MUST be provided for this
purpose, and it is recommended to provide a reasonable default value
for this timer.
What does "such a procedure" refers to?
s/recommended/RECOMMENDED/?
3.1.7. Per PE-CE link BFD Discriminator
The following approach is defined for the fast failover in response
to the detection of PE-CE link failures, in which UMH selection for a
given C-multicast route takes into account the state of the BFD
session associated with the state of the upstream PE-CE link.
3.1.7.1. Upstream PE Procedures
For each protected PE-CE link, the upstream PE initiates a multipoint
BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward
downstream PEs. A downstream PE monitors the state of the p2mp
session as MultipointTail and MAY interpret transition of the BFD
session into Down state as the indication of the associated PE-CE
link being down.
Since the BFD packets are sent over the P2MP tunnel not the PE-CE link, my
understanding is that the BFD discriminator is still for the tunnel and not
tied to the PE-CE link; but different from the previous case, the root will
stop sending BFD messages when it detects the PE-CE link failure. As far as the
egress PEs are concerned, they don't know if it is the tunnel failure or PE-CE
link failure.
If my understanding is correct, the wording should be changed.
... If the route to the
src/RP changes such that the RPF interface is changed to be a new PE-
CE interface, then the upstream PE will update the S-PMSI A-D route
with included BGP-BFD Attribute so that value of the BFD
Discriminator is associated with the new RPF link.
If the RPF interface changes on the upstream PE, why should it update the route
to send a new discriminator? As long as there is a new RPF interface couldn't
the upstream PE do nothing but start tracking the new RPF interface?
Regardless which way (the currently described way and my imagined way), some
text should be added to discuss how the downs
