Ali, Thanks for your replies.
On Sun, Oct 11, 2020 at 9:06 PM Ali Sajassi (sajassi) <saja...@cisco.com> 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" <nore...@ietf.org> 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. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
