On Thu, Feb 4, 2021 at 10:56 PM Ali Sajassi (sajassi) <[email protected]> wrote: > > Hi Erik, > > Please see my reply marked w/ AS>> > > On 12/9/20, 7:50 PM, "Erik Kline" <[email protected]> wrote: > > Ali, > > Thanks for your replies. > > On Sun, Oct 11, 2020 at 9:06 PM Ali Sajassi (sajassi) <[email protected]> > 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" <[email protected]> > 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 modified the 1st sentence to say "... whenever a PE performs a host IP > lookup for a packet that is routed, ....". This way we clarify that the > TTL/HL decrement is for routed packets and NOT for bridged packets that are > forwarded w/ TTL/HL intact or NS/NA that get terminated. > > > > [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). > > AS>> OK, I removed the explicit mentioned of non-link-local addresses. > > Thanks for the reference to the extended mobility doc. > > AS>> You're welcome! > > Cheers, > Ali >
Thanks for the updates. I think there might still be complications for TSes with multiple IPv6 GUAs (which can be very normal is in line with BCP 204), but I guess time will tell and other docs / future work will have a chance to resolve any issues encountered. One quick nit: I saw "expexted" in section 7; probably should be "expected". _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
