Hi Erik,
Please see my reply marked w/ AS>>
On 12/9/20, 7:50 PM, "Erik Kline" <ek.i...@gmail.com> wrote:
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 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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
