Re: [bess] comment on draft-ietf-bess-ir

[Eric C Rosen <[e-mail]>]

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