Re: [bess] draft-ietf-bess-evpn-prefix-advertisement-05 comments

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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?

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

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

> 
>        (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:

     IP 4 ---+
     SN 2 --+
                 | TS2
            |--+
   SN1  |
            |--+
                 | TS3
     SN 3 --+
     IP 5 ---+

Jeffrey