Re: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
On Thu, Feb 4, 2021 at 10:56 PM Ali Sajassi (sajassi) wrote: > > Hi Erik, > > Please see my reply marked w/ AS>> > > On 12/9/20, 7:50 PM, "Erik Kline" wrote: > > Ali, > > Thanks for your replies. > > On Sun, Oct 11, 2020 at 9:06 PM Ali Sajassi (sajassi) > 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" > 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
Re: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
Hi Erik, Please see my reply marked w/ AS>> On 12/9/20, 7:50 PM, "Erik Kline" wrote: Ali, Thanks for your replies. On Sun, Oct 11, 2020 at 9:06 PM Ali Sajassi (sajassi) 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" 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
Re: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
Ali, Thanks for your replies. On Sun, Oct 11, 2020 at 9:06 PM Ali Sajassi (sajassi) 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" 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 > >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
Re: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
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" 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 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
[bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/ -- 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? * 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...? [ 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. [ section 7 ] * Is there a reference for IRB-EXT-MOBILITY? * 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? -- 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. [ section 1 ] * IP-VRF definition: s/VPN Routing.../Virtual Routing/? [ 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? [ 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. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
