Hi Jeffrey, Pls see in-line. I’ve made the two minor changes below, but I won’t publish rev 07 until we need to make more changes. Is it ready now from your perspective?
Thanks. Jorge On 10/16/17, 8:12 PM, "Jeffrey (Zhaohui) Zhang" <[email protected]> wrote: Hi Jorge, > +----------+----------+----------+------------+----------------+ > | ESI | GW-IP | MAC* | Label | Overlay Index | > |--------------------------------------------------------------| > | Non-Zero | Zero | Zero | Don't Care | ESI | > | Non-Zero | Zero | Non-Zero | Don't Care | ESI | > | Zero | Non-Zero | Zero | Don't Care | GW-IP | > | Zero | Zero | Non-Zero | Zero | MAC | > | Zero | Zero | Non-Zero | Non-Zero | MAC or None** | > | Zero | Zero | Zero | Non-Zero | None(IP NVO)***| > +----------+----------+----------+------------+----------------+ > > The fifth row is like a variation of the fourth row; why isn't there a > corresponding variation for each of the first three rows? The following > paragraph mentioned earlier seems to apply to all situations. > [JORGE] in rows 4 and 5, the label value 0 or non-0 has a meaning. In the first > three rows, the label doesn’t have any meaning. Can you elaborate on "the label does not have any meaning", especially for row #2? [JORGE] since an overlay index is used, a recursive resolution is needed. Hence the label is not used to forward packets. “Don’t Care” means a valid 0 or non-zero label value should be ignored. > > I struggled with the "IP NVO" in the sixth row because clearly this is MPLS > tunnel not IP tunnel. Then I realized that "IP" here refers to the payload not > the tunnel type: > > IP NVO tunnel: it refers to Network Virtualization Overlay tunnels > with IP payload (no MAC header in the payload). > > I have to say that "IP NVO tunnel" is a little misleading. > [JORGE] well, that’s why we put it in the terminology in section 1. Let me > know if you think the description requires clarification. I’ll leave it as it is for > the time being. For the particular confusion that I had with the sixth row, we could probably just remove "IP NVO". You have a *** note for it anyway. [JORGE] ok, done. > > > In section 4.1: > > o Based on the MAC-VRF10 route-target in DGW1 and DGW2, the IP > Prefix route is also imported and SN1/24 is added to the IP- > VRF with Overlay Index IP2 pointing at the local MAC-VRF10. We > assume the RT-5 from NVE2 is preferred over the RT-5 from > NVE3. Should ECMP be enabled in the IP-VRF and both routes > equally preferable, SN1/24 would also be added to the routing > table with Overlay Index IP3. > > The last two sentences seem to be contradicting. One says "preferred over" > and the other says "equally preferable". > [JORGE] ok, I clarified it with this sentence: > “In this example, we assume the RT-5 from NVE2 is preferred over the RT-5 > from NVE3. If both routes were equally preferable and ECMP enabled, SN1/24 > would also be added to the routing table with Overlay Index IP3.” The original text is actually fine. I mis-read it. [JORGE] ok > > (5) When the packet arrives at NVE2: > o Based on the tunnel information (VNI for the VXLAN case), the > MAC-VRF10 context is identified for a MAC lookup. > o Encapsulation is stripped-off and based on a MAC lookup > (assuming MAC forwarding on the egress NVE), the packet is > forwarded to TS2, where it will be properly routed. > > If the destination is actually on the TS3 side, how does TS2 send traffic to > the final destination? Unless the topology is actually like the one in section 4.2 > traffic will get blackholed? > [JORGE] yes the topology for SN1 is the same. But we wanted to add more > subnets and hosts. I added: “We assume SN1/24 is dual-homed to NVE2 and > NVE3.” It would be nice the redraw the picture to indicate so. For example: [JORGE] ok, done. IP 4 ---+ SN 2 --+ | TS2 |--+ SN1 | |--+ | TS3 SN 3 --+ IP 5 ---+ Jeffrey _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
