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

[Erik Kline <[e-mail]>]

Ali,

Thanks for your replies.

On Sun, Oct 11, 2020 at 9:06 PM Ali Sajassi (sajassi) <[e-mail]> wrote:
>
> 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."

I don't quite understand what this text should be telling me.  IPv6
Neighbor Solicitations must be sent with a Hop Limit of 255 (4861
S4.3) and "HL==255" is a validation check performed on receipt (4861
S7.1.1).  The same goes for the Neighbor Advertisement replies.

I think your answers above clarifying the mixed routing and bridging
situation (depending on configuration) probably address my original
concern (that NS/NA HLs would not get decremented since they're
bridged; when they're routed they obviously can't be forwarded).  If
that's true, it might be better to undo this particular paragraph
addition, and I apologize for my confusion.

> [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 ]
>
>     * 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.”

It's not clear to me that IPv6 link-local addresses need to be called
out explicitly.  I simply meant that for IPv6 nodes would likely have
at least two addresses (one LL, one GUA).

Thanks for the reference to the extended mobility doc.