Hi Eric, Please see inline below,
-----Original Message----- From: Eric C Rosen [mailto:ero...@juniper.net] Sent: Monday, September 21, 2015 8:36 AM To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess...@ietf.org Cc: bess@ietf.org Subject: Re: [bess] comment on draft-ietf-bess-ir > 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. [Lucy] An patent for a mcast group can not consider the route to have been withdrawn and replaced because of RT is not indicate the parent. The parent must check if the leaf A-D for the mcast is from its child. There is a case, a patent for a mcast group receives an leaf A-D of the group from a downstream node whose patent is not this patent. In this case, the patent must not treat it as implicitly withdraw. The solution requires that, upon receiving leaf A-D route, every node does if it is the patent for this mcast, if sending node is its child, if RT is the same as the node address update the mcast state as update else treat as withdraw and update accordingly; end if else do nothing; end if else if RT is the same as the node address update the mcast state as new join else do nothing end if end if [Lucy] BGP is a distribution protocol and require every node performing the logic, it does not scale. If we use BGP as signaling purpose, a receiving node should first check if the RT is the same as the node address; if not, do nothing; if yes, act on it. This is a simpler logic. This requires that a child node has to explicitly send the withdraw leaf A-D when changing its patent; as a result, the parent no longer need to sync with the child on "make before break" process. -end > 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. [Lucy] Leaf A-D is for downstream to inform upstream patent, shouldn't be the same for segmented P-tunnels (IR) or non-segmented P-tunnels? If not, please explain. > 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. [Lucy] The case you describe is the case that N1 also merges packets from tunnel K1 and K2. At an egress node, it knows which receivers should get a packet from K1 and which from K2. In another case, the N1 may have two downstream neighbors, one is for K1 tunnel only and another for K2 tunnel only, although N1 allocates the same label for both, downstream nodes are different, it is OK to merge. IMO: this also makes simpler for some case. Thanks, Lucy _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
