Think more about using BGP mechanism to achieve the make before
break at a child.
The child can do it without parent cooperation. When a child changes
the parent for a Leaf A-D route, it first sends out the route with
the new parent address encoded in RT; when old parent receives the
route, it does not need to take any action on it;
Note that if Constrained Route Distribution (RFC4684) is running, the
old parent will see an explicit withdraw when the RT is changed.
Even if Constrained Route Distribution is not running, once the
attributes of a route are modified, the route is considered to have been
implicitly withdrawn, and the route with the new attributes is
considered to be a replacement route. (See section 3.1 of RFC 4271.)
So once the RT no longer identifies the old parent, the old parent must
consider the route to have been withdrawn and replaced. Since the
replacement route does not identify the old parent, it does not impact
the old parent's multicast state.
The old parent updates multicast state and new parent do nothing when
receiving the withdraw leaf A-D route.
As indicated above, the old parent will have seen an implicit or
explicit withdraw as soon as the RT was changed.
Further, if the new parent sees a withdraw, it cannot decide to maintain
the route anyway, as this would violate BGP semantics.
Regarding suppress the non-parent node to re-distribute the leaf A-D
route, if we take RR as an exception case and require RR to
re-distribute leaf A-D; IMO, it MAY work too.
There are a variety of deployment scenarios in which a received Leaf A-D
route must be redistributed, even by a router that is not identified in
the route's RT and that is not an RR. For instance, this will be
necessary if non-segmented P-tunnels are being used, but the routes need
to be distributed through multiple EBGP sessions in order to travel from
egress to ingress. The only time it is safe to not redistribute a Leaf
A-D route is when one knows that the route has already reached its
target, or that it will reach its target through some other path. There
is no simple set of rules to determine this. If you want to constrain
the distribution of the Leaf A-D routes, you either need to use
Constrained Route Distribution, or to set up policies that are specific
to a particular deployment.
I suggest to relax the second rule in Section 6.2, i.e. no need to
require N to have exact same set of downstream neighbors in two
tunnels. For example, if K1 has downstream neighbors n1~n10 and K2
has downstream neighbors n2-n10. N node can assign a single label for
the upstream for both tunnels. As a result, the packet with this
label from upstream node will be sent to downstream neighbors n1-n10;
n1 accepts the packets that associate with K1 and discard the packets
that associate with K2. N2-N10 will accept the packets that associate
with either K1 or K2.
As Jeffrey has explained, there is no way in this scenario for N1 to
determine that a particular packet should be associated with K1 rather
than with K2. Suppose the parent node receives packet P1 on tunnel K1
and packet P2 on tunnel K2. Since those packets carry the same label,
the parent node doesn't know which packet has arrived on which tunnel.
The parent node will just do a label swap and send the packets along to
N1-N10. When N1 gets packets P1 and P2, they both have the same label,
and therefore N1 has no way to determine that one of the two packets is
on tunnel K2 and should be discarded.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
