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

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

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" <[e-mail]> 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