Hi Jeffery, I did not complete the typing in previous mail, which makes unclear text. Revised text is inline below.
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] Sent: Wednesday, September 02, 2015 9:10 AM To: Lucy yong; 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, If downstream neighbor n1 relies on IP forwarding, it can discard the packet associated with k2 after an IP lookup. But if it does not (e.g., it uses label switching - because it is a segmentation point and has its own downstream segment), then it won't be able to discard traffic and will continue to forward traffic downstream. [Lucy] the rule in 6.2 does not require downstream neighbor to assign the same label for K1 and K2. If it is, it follows its parent behavior described in the draft. Agree if all parent for both to meet the rules specified in Section 6.2, two tunnels share the same labels on the upstream path until two tunnels have different parent again. Besides, w/o requiring the set of matching neighbors (and the matching encapsulation for each neighbor), it becomes hard for N to decide if it can advertise the same label for k1 and k2. [Lucy] Maybe not, N can allocate the same label for two tunnels if all or >XX% downstream neighbors are the same for K1 and K2 such as 90%. The higher %, the less packets will be discarded at downstream nodes. It is true that the hard requirements causes more updates when downstream come and go, but that dynamic does not increase the complexity of the logic that allocates the label, and there are ways (e.g. dampening) to mitigate the thrashing. One may argue that the dampening will cause the same issue I mentioned in the previous paragraph, but I think it's better to have precise/hard rules on label allocation. [Lucy] However it is increasing router process, state changes, and forwarding update, which means increasing the complexity. Thanks, Lucy Jeffrey From: Lucy yong [mailto:lucy.y...@huawei.com] Sent: Wednesday, September 02, 2015 9:47 AM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; 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 Jeffery, Let me clarify, 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. The reason I point out the section 9 is that at one time, K1 and K2 may have the same set of downstream neighbors, at another time, another downstream neighbors may advertise leaf A-D route for K1 but not K2, now N will have different set of downstream neighbors, N has to allocate different label for K1. Since leaf A-D route can by dynamically advertised by downstream neighbor for join, withdraw, parent change; rule #2 in section 6.2 makes sharing label or merge tunnel a hard condition to satisfy. If rule #2 is not satisfied, the node allocates different label for each tunnel, which results a large table; and changing the label on fly makes more complex for the parent, parent of patent, as so on. Regards, Lucy From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] Sent: Tuesday, September 01, 2015 3:16 PM To: Lucy yong; 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 Lucy, > The relaxed rule make easier to qualify the condition. Section 6.2 and section 9 are independent. Section 6.2 is about sharing label (for the same parent) among two different tunnels; section 9 is about the child picking a new parent for the same tunnel. I had thought your "relaxed rule" is about section 9 - let the child manage the make-before-break w/o involving parent. Now it seems that you're referring to section 6.2, and it's not clear what the relaxed rule is. Jeffrey From: Lucy yong [mailto:lucy.y...@huawei.com] Sent: Tuesday, September 01, 2015 4:08 PM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; 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 From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] Sent: Tuesday, September 01, 2015 3:01 PM To: Lucy yong; 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 Lucy, Please see zzh2> below. From: Lucy yong [mailto:lucy.y...@huawei.com] Sent: Tuesday, September 01, 2015 3:48 PM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; 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 Jeffery, Thank you for your quick reply. To clarify, the first part of my previous email is to state what are specified in the draft. Starting "Since the essential rule" is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; 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. [Lucy] Please clarify: both have the same forwarding state for the downstream segment at a time or forever? Section 9 states that many reason may cause to change the parents for a leaf A-D. Zzh2> As long as they still share the same downstream forwarding state. The motivation for this optimization is to reduce the forwarding state on this and upstream routers when possible. [Lucy] I understand this benefit. The relaxed rule make easier to qualify the condition. 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. [Lucy] This is always valid to do. My point is when it is proper to have a shared label. Zzh2> It's valid to share label as long as your downstream forwarding state are the same for the two tunnels. [Lucy] IMO: this is not necessary. Without the same downstream forwarding state, two tunnels can share the label too as long as we state the downstream operation properly. Thanks, Lucy 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. [Lucy] why can't the child send the Leaf A-D for new patent first to the new parent and send withdraw Leaf A-D to old Patent the later when it stops accepting the packet from old-parent? In fact, this is what I propose below. Zzh2> For a particular PMSI route, you can only have one instance of the Leaf A-D route. If it contains only the RT for the new parent, then the old parent will get an implicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to the new parent and that's not good. Jeffrey Thanks, Lucy 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
