Please see inline. From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] Sent: Tuesday, September 01, 2015 2:45 PM To: Lucy yong; draft-ietf-bess...@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir
Two corrections - thanks for Eric to point out: > When a child changes the RT value because it picks a new parent, the old > parent will get a withdraw - not that it gets the updated route (with the new > RT) first and then a withdraw later. More accurately, it's that the old parent will get the updated route (with the new RT) which serves as an implicit withdraw (because the old RT that caused the importation is no longer present). If RTC is used, then the old parent does get a withdraw (and you can't control the time it is done). [Lucy] IMO: This is the part that can be improved. > Perhaps this can be done by the child to include the RT for the new parent > and the RT for the old parent for a while, and then remove the RT for the old > parent later That is actually not feasible. The updated route has the label allocated for the new parent and should not be imported by the old parent. [Lucy] agree. However, a child can use one leaf A-D with the new parent with a new label and later send withdraw leaf A-D to the old parent when stop accepting the packet from ole parent that removes the old label too. Lucy Jeffrey From: Jeffrey (Zhaohui) Zhang Sent: Tuesday, September 01, 2015 3:27 PM To: 'Lucy yong' <lucy.y...@huawei.com<mailto:lucy.y...@huawei.com>>; draft-ietf-bess...@tools.ietf.org<mailto:draft-ietf-bess...@tools.ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org> Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess...@tools.ietf.org<mailto:draft-ietf-bess...@tools.ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org> Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS number is used as the tree root ID and RT is used for Parent identifier. The implementation requires each parent to track all its children and each child selects one parent. Zzh> While in a separate thread you and I talked about AS number identifying the tree root for an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel, whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocate a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two different tunnels. Suppose there are two tunnels, both have the same forwarding state for the downstream segment, then the upstream can share the same label. Section 9 describes that the solution is able to support dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in section 6.2 becomes a near impossible condition because the Leaf A-D route at downstream may change for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The more complicated label allocation scheme in the section allows for different tunnel segments to share the same forwarding state, and is an optimization. The implementation of that is not infeasible. Section 9 further describes "the make before break" implementation and requires some cooperation between patent and its child who is changing to a new parent; that is: the patent detects the change from RT value changes and update its state (not as parent for the child), but continually send the packet in data plane until receiving the withdraw Leaf A-D route from the child; the child sends the leaf A-D with the new parent identified by IP address-specific RT, but continually acceptes the packets from old-patent for a while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the old parent will get a withdraw - not that it gets the updated route (with the new RT) first and then a withdraw later. Since the essential rule in this mechanism is for each child to select one and only one patent, the child node can implement "make before break" without parent assistant. Thus, patent does not need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Leaf A-D route. Let the child to manage it. If two nodes send the same packet to a child, the child only accepts the packet from its parent and discards a packet from non parent now as the essential rule. When a child changes parents, it just needs to continually accept the packet from old parent for a while, after accepting the packet from the new UMH, it sends the withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new parent and the RT for the old parent for a while, and then remove the RT for the old parent later. The drawback is that an additional route update is needed. The essential rule can relax the #2 rule in section 6.2, i.e. no need to restrict N's forwarding state for K1 and K2 are exactly same, i.e. the same set of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) the packet is from non-patent node; 2) the node never advertises for the corresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label in upstream path, an intermediate node can have a proper algorithm for label allocation. Does this make a sense? Comment? Thanks. Lucy
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
