Re: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Erik,

Thanks for your comments and sorry to missed them in first place, please see my replies in line marked w/ [AS]:

On 7/14/20, 11:22 PM, "Erik Kline via Datatracker" <[e-mail]> wrote:

    Erik Kline has entered the following ballot position for
    draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss


    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------

    [ general ]

    * Can you give an example of what happens to non-IPv4/IPv6 Ethernet packets
      received at the NVE/PE?  Do they get bridged, and if so how far?  What
      happens if a host in BT1 ARPs for IPv4 address associated with a TS in
      a different BT?

[AS] L2 packet (non-ARP/ND packet) gets bridged; however, ARP/ND packets from the host for its IP default GW gets terminated at the PE and process by it. Section 4.1 describes this in details and it provides an example of it at the bottom of the section. Since the PE acts as the IP default GW for the host, all packets to other TSes in other subnets gets forwarded to the PE (to its IP default GW).

    * Where there are multiple prefixes in an IP-VRF, is there a constraint that
      any other IP-VRF that contains one of the prefixes must contain all of them?
      Perhaps that's in 7432...?

[AS] IP and MAC addresses for a given host is advertised with its corresponding Route Targets as described at the bottom of section 3, and in sections 5.2, 6.2 9.1.1, and 9.2.1. Any PE that has an IP-VRF for that tenant/host, imports the IP route into its VRF upon receiving it.  

    [ sections 4, 5.4, 5.4, 6.3, 6.4, 9.1.2, 9.2.2 ]

    * Please document what happens to IPv4 TTL/IPv6 Hop Limit values as they
      cross various NVEs/PEs.

[AS] Added the following to section 4:
"It should be noted that whenever a PE performs a host IP lookup for a packet,  
   IPv4 TTL or IPv6 hop limit for that packet is decremented by one and if it 
   reaches zero, the packet is discarded. In case of symmetric IRB, the TTL/hop
   limit is decremented by both ingress and egress PEs (once by each); whereas,
   in case of asymmetric IRB, the TTL/hop limit is decremented only once by the
   ingress PE."

[AS] I also added similar sentences to sections 5.4, 5.5, 6.3, and 9.1.2, and 9.2.2. This addition is not applicable to section 6.4.

    [ section 7 ]

    * Is there a reference for IRB-EXT-MOBILITY?

[AS] Yes, there were couple of other comments on this and I have fixed that already. 

    * The two statements:

      (1) "Although the language used in this section is for IPv4 ARP,
          it equally applies to IPv6 ND."

      (2) "If there is [a] many-to-one relationship such that there are many host
          IP addresses correspond[ing] to a single host MAC address ..., then to
          detect host mobility, the procedures in [IRB-EXT-MOBILITY] must be
          exercised..."

      are in direct conflict.  All IPv6 hosts having at least one non-link-local
      unicast address will have more than one IP address per MAC and this section,
      or even this document, would not apply?

[AS] I modified the paragraph to call out non-link-local address for IPv6 explicitly: 

“If there is many-to-one relationship such that there are many host IP 
   addresses (non-link-local unicast addresses for IPv6)
   corresponding to a single host MAC address or there are many host MAC addresses 
   corresponding to a single IP address (non-link-local unicast address for IPv6), 
   then to detect host mobility, the procedures in
   <xref target="I-D.ietf-bess-evpn-irb-extended-mobility"/>
   must be exercised followed by the procedures described below.”


    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    [ general ]

    * I believe this is true, but can you just state here (not in the doc) that
      there are no multi-link subnets that can be created with this model as
      defined in RFC 4903? It seems like everything is as it should be, but just
      to double-check.

[AS] I don’t see an multi-link subnet issue here. 

    [ section 1 ]

    * IP-VRF definition: s/VPN Routing.../Virtual Routing/?

[AS] Done.

    [ section 3 ]

    * 2nd to last paragraph: Is any of this still true for a setup that
      involves multiple IPv6 prefixes per BD, maybe I misunderstood
      (or maybe this assumed single prefix per broadcast domain w/ IPv4-only?).

      Perhaps avoid suggesting there's a 1:1 relationship and use phrases
      likes "at least as many X as there are Y" or something?

[AS] The paragraph says "typically", so it doesn't mandate 1:1 relationship.  

    [ section 4 ]

    * ARP table: a less IPv4-specific name, even though it's define to hold both
      IPv4 and IPv6 associations, would be "neighbor table".  That might be
      overloaded in routing contexts so no need to change it.

[AS] There was another comments similar to this so I added NDP cache for IPv6. 


Thanks again,
Ali