Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)
Thank you Ali The text should improve the quality of the document Regards -éric -Original Message- From: "Ali Sajassi (sajassi)" Date: Thursday, 3 September 2020 at 18:39 To: Eric Vyncke , The IESG Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" , "bess-cha...@ietf.org" , "bess@ietf.org" , Zhaohui Zhang Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT) Hi Eric, I add the following sentences in section 2 to provide further clarification to your point: " It should be noted that if an IP-VRF in a NVE is configured for IPv6 and that NVE receives IPv4 traffic on the corresponding VLAN, then the IPv4 traffic is treated as L2 traffic and it is bridged. Also vise versa, if an IP-VRF in a NVE is configured for IPv4 and that NVE receives IPv6 traffic on the corresponding VLAN, then the IPv6 traffic is treated as L2 traffic and it is bridged." Cheers, Ali On 9/1/20, 1:46 AM, "Eric Vyncke (evyncke)" wrote: Thank you Ali for your reply. My comments are non-blocking anyway but I am still not too happy with your reply to - section 2, I still find the text not really clear - unsure whether I understand the reasoning on section 4.1 Else, happy with all your changes => they will improve the document Regards -éric -Original Message- From: "Ali Sajassi (sajassi)" Date: Tuesday, 1 September 2020 at 00:25 To: Eric Vyncke , The IESG Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" , "bess-cha...@ietf.org" , "bess@ietf.org" , Zhaohui Zhang Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT) Hi Eric, Thanks for your review and your comments, please refer to my replies inline marked with [AS]. On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker" wrote: Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection 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/ -- COMMENT: -- Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs). I hope that this helps to improve the document, Regards, -éric PS: as a side note, I found that this document uses too many acronyms even for short words (e.g., "SN" instead of "Subnet"). There are also very long sentences that, when combined with acronyms, make reading difficult. == COMMENTS == -- Section 2 -- About "to bridge non-IP and intra-subnet traffic and to route inter-subnet IP traffic": suggest to clarify the text when the IP-VRF is IPv6 only, then, (I assume) that IPv4 packets will be bridged and not IP-forwarded (and vice-versa). [AS] the above quoted text is provided as an example and it should be clear enough Without making the sentence to verbose. -- Section 4.1 -- Suggest to replace "then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) for that TS." by "then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) or Router Advertisement (RA) for that TS" because routers MAC addresses are also advertised by Router Advertisements. [AS] I don't think the IRB interface MAC address in the initial ARP reply can be used In RA because it is a multicast packet - i.e., the MAC address of old IRB interface and the New IRB interface cannot
Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)
Hi Eric,
I add the following sentences in section 2 to provide further clarification to
your point:
" It should be
noted that if an IP-VRF in a NVE is configured for IPv6 and that NVE
receives IPv4 traffic on the corresponding VLAN, then the IPv4
traffic is treated as L2 traffic and it is bridged. Also vise versa,
if an IP-VRF in a NVE is configured for IPv4 and that NVE receives
IPv6 traffic on the corresponding VLAN, then the IPv6 traffic is
treated as L2 traffic and it is bridged."
Cheers,
Ali
On 9/1/20, 1:46 AM, "Eric Vyncke (evyncke)" wrote:
Thank you Ali for your reply.
My comments are non-blocking anyway but I am still not too happy with your
reply to
- section 2, I still find the text not really clear
- unsure whether I understand the reasoning on section 4.1
Else, happy with all your changes => they will improve the document
Regards
-éric
-Original Message-
From: "Ali Sajassi (sajassi)"
Date: Tuesday, 1 September 2020 at 00:25
To: Eric Vyncke , The IESG
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org"
, "bess-cha...@ietf.org"
, "bess@ietf.org" , Zhaohui Zhang
Subject: Re: Éric Vyncke's No Objection on
draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)
Hi Eric,
Thanks for your review and your comments, please refer to my replies
inline marked with [AS].
On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker"
wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection
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/
--
COMMENT:
--
Thank you for the work put into this document.
Please find below a couple of non-blocking COMMENTs (and I would
appreciate a
reply to each of my COMMENTs).
I hope that this helps to improve the document,
Regards,
-éric
PS: as a side note, I found that this document uses too many
acronyms even for
short words (e.g., "SN" instead of "Subnet"). There are also very
long
sentences that, when combined with acronyms, make reading difficult.
== COMMENTS ==
-- Section 2 --
About "to bridge non-IP and intra-subnet traffic and to route
inter-subnet IP
traffic": suggest to clarify the text when the IP-VRF is IPv6 only,
then, (I
assume) that IPv4 packets will be bridged and not IP-forwarded (and
vice-versa).
[AS] the above quoted text is provided as an example and it should be
clear enough
Without making the sentence to verbose.
-- Section 4.1 --
Suggest to replace "then the IRB interface MAC address MUST be the
one used in
the initial ARP reply or ND Neighbor Advertisement (NA) for that
TS." by "then
the IRB interface MAC address MUST be the one used in the initial
ARP reply or
ND Neighbor Advertisement (NA) or Router Advertisement (RA) for
that TS"
because routers MAC addresses are also advertised by Router
Advertisements.
[AS] I don't think the IRB interface MAC address in the initial ARP
reply can be used
In RA because it is a multicast packet - i.e., the MAC address of old
IRB interface and the
New IRB interface cannot be sent in a single multicast packet.
-- Section 5.1 --
Should also mention NDP when writing "(via an ARP request)" in the
first
paragraph.
[AS] Done.
In the same vein, please add "NDP cache" to "Furthermore, it adds
this TS's MAC
and IP address association to its ARP table".
[AS] Done.
As I am not an expert in EVPN, I am puzzled by the math about the
Length field
"either 40 (if IPv4 address is carried) or 52 (if IPv6 address is
carried)."
[AS] for IPv6, the NLRI has 12 additional bytes.
-- Section 5.2 --
This section also only mentions IPv4 ARP table, please
Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)
Thank you Ali for your reply. My comments are non-blocking anyway but I am still not too happy with your reply to - section 2, I still find the text not really clear - unsure whether I understand the reasoning on section 4.1 Else, happy with all your changes => they will improve the document Regards -éric -Original Message- From: "Ali Sajassi (sajassi)" Date: Tuesday, 1 September 2020 at 00:25 To: Eric Vyncke , The IESG Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" , "bess-cha...@ietf.org" , "bess@ietf.org" , Zhaohui Zhang Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT) Hi Eric, Thanks for your review and your comments, please refer to my replies inline marked with [AS]. On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker" wrote: Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection 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/ -- COMMENT: -- Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs). I hope that this helps to improve the document, Regards, -éric PS: as a side note, I found that this document uses too many acronyms even for short words (e.g., "SN" instead of "Subnet"). There are also very long sentences that, when combined with acronyms, make reading difficult. == COMMENTS == -- Section 2 -- About "to bridge non-IP and intra-subnet traffic and to route inter-subnet IP traffic": suggest to clarify the text when the IP-VRF is IPv6 only, then, (I assume) that IPv4 packets will be bridged and not IP-forwarded (and vice-versa). [AS] the above quoted text is provided as an example and it should be clear enough Without making the sentence to verbose. -- Section 4.1 -- Suggest to replace "then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) for that TS." by "then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) or Router Advertisement (RA) for that TS" because routers MAC addresses are also advertised by Router Advertisements. [AS] I don't think the IRB interface MAC address in the initial ARP reply can be used In RA because it is a multicast packet - i.e., the MAC address of old IRB interface and the New IRB interface cannot be sent in a single multicast packet. -- Section 5.1 -- Should also mention NDP when writing "(via an ARP request)" in the first paragraph. [AS] Done. In the same vein, please add "NDP cache" to "Furthermore, it adds this TS's MAC and IP address association to its ARP table". [AS] Done. As I am not an expert in EVPN, I am puzzled by the math about the Length field "either 40 (if IPv4 address is carried) or 52 (if IPv6 address is carried)." [AS] for IPv6, the NLRI has 12 additional bytes. -- Section 5.2 -- This section also only mentions IPv4 ARP table, please add IPv6 NDP cache. [AS] Done. -- Section 6.1 -- Same comments as for section 5.1 AS] Done. -- Section 6.2 -- Same comments as for section 5.2 [AS] Done. -- Section 7 -- Good to state "Although the language used in this section is for IPv4 ARP, it equally applies to IPv6 ND."; even if I would have preferred to use by default IPv6 ND ;-) [AS] yes, the quoted sentence already exist. Please note that in IPv6 there are often at least TWO IPv6 addresses per MAC (one link-local fe80::... and one global); so, "In the following subsections, it is assumed that the MAC and IP addresses of a TS have one-to-one relationship (i.e., there is one IP address per MAC address and vice versa). " is obviously never
Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)
Hi Eric, Thanks for your review and your comments, please refer to my replies inline marked with [AS]. On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker" wrote: Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection 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/ -- COMMENT: -- Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs). I hope that this helps to improve the document, Regards, -éric PS: as a side note, I found that this document uses too many acronyms even for short words (e.g., "SN" instead of "Subnet"). There are also very long sentences that, when combined with acronyms, make reading difficult. == COMMENTS == -- Section 2 -- About "to bridge non-IP and intra-subnet traffic and to route inter-subnet IP traffic": suggest to clarify the text when the IP-VRF is IPv6 only, then, (I assume) that IPv4 packets will be bridged and not IP-forwarded (and vice-versa). [AS] the above quoted text is provided as an example and it should be clear enough Without making the sentence to verbose. -- Section 4.1 -- Suggest to replace "then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) for that TS." by "then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) or Router Advertisement (RA) for that TS" because routers MAC addresses are also advertised by Router Advertisements. [AS] I don't think the IRB interface MAC address in the initial ARP reply can be used In RA because it is a multicast packet - i.e., the MAC address of old IRB interface and the New IRB interface cannot be sent in a single multicast packet. -- Section 5.1 -- Should also mention NDP when writing "(via an ARP request)" in the first paragraph. [AS] Done. In the same vein, please add "NDP cache" to "Furthermore, it adds this TS's MAC and IP address association to its ARP table". [AS] Done. As I am not an expert in EVPN, I am puzzled by the math about the Length field "either 40 (if IPv4 address is carried) or 52 (if IPv6 address is carried)." [AS] for IPv6, the NLRI has 12 additional bytes. -- Section 5.2 -- This section also only mentions IPv4 ARP table, please add IPv6 NDP cache. [AS] Done. -- Section 6.1 -- Same comments as for section 5.1 AS] Done. -- Section 6.2 -- Same comments as for section 5.2 [AS] Done. -- Section 7 -- Good to state "Although the language used in this section is for IPv4 ARP, it equally applies to IPv6 ND."; even if I would have preferred to use by default IPv6 ND ;-) [AS] yes, the quoted sentence already exist. Please note that in IPv6 there are often at least TWO IPv6 addresses per MAC (one link-local fe80::... and one global); so, "In the following subsections, it is assumed that the MAC and IP addresses of a TS have one-to-one relationship (i.e., there is one IP address per MAC address and vice versa). " is obviously never the case for IPv6. I understand that the rest of the paragraph explains how to handle the case but it could be easier to treat IPv6 in a separate sentence. -- Section 7.1 -- While about mobility, this section appears to be also applicable to Duplicate Address Detection but is unclear on what to do when the same IP but different MAC (i.e., an actual IP address collision). Or is it covered in other documents? [AS] duplicate MACs are covered in RFC 7432. == NITS == -- Section 1 -- "BD and subnet are equivalent terms" while in the rest of the document "IP subnet" is often used. If "subnet IP" and "subnet" are synonyms, then I suggest to keep using one for consistency or at least mention that "IP subnet" and "subnet" are the same concept (or explain the difference if they are not identical). [AS] Added clarification that "subnet" means "IP subnet". ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection 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/ -- COMMENT: -- Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs). I hope that this helps to improve the document, Regards, -éric PS: as a side note, I found that this document uses too many acronyms even for short words (e.g., "SN" instead of "Subnet"). There are also very long sentences that, when combined with acronyms, make reading difficult. == COMMENTS == -- Section 2 -- About "to bridge non-IP and intra-subnet traffic and to route inter-subnet IP traffic": suggest to clarify the text when the IP-VRF is IPv6 only, then, (I assume) that IPv4 packets will be bridged and not IP-forwarded (and vice-versa). -- Section 4.1 -- Suggest to replace "then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) for that TS." by "then the IRB interface MAC address MUST be the one used in the initial ARP reply or ND Neighbor Advertisement (NA) or Router Advertisement (RA) for that TS" because routers MAC addresses are also advertised by Router Advertisements. -- Section 5.1 -- Should also mention NDP when writing "(via an ARP request)" in the first paragraph. In the same vein, please add "NDP cache" to "Furthermore, it adds this TS's MAC and IP address association to its ARP table". As I am not an expert in EVPN, I am puzzled by the math about the Length field "either 40 (if IPv4 address is carried) or 52 (if IPv6 address is carried)." -- Section 5.2 -- This section also only mentions IPv4 ARP table, please add IPv6 NDP cache. -- Section 6.1 -- Same comments as for section 5.1 -- Section 6.2 -- Same comments as for section 5.2 -- Section 7 -- Good to state "Although the language used in this section is for IPv4 ARP, it equally applies to IPv6 ND."; even if I would have preferred to use by default IPv6 ND ;-) Please note that in IPv6 there are often at least TWO IPv6 addresses per MAC (one link-local fe80::... and one global); so, "In the following subsections, it is assumed that the MAC and IP addresses of a TS have one-to-one relationship (i.e., there is one IP address per MAC address and vice versa). " is obviously never the case for IPv6. I understand that the rest of the paragraph explains how to handle the case but it could be easier to treat IPv6 in a separate sentence. -- Section 7.1 -- While about mobility, this section appears to be also applicable to Duplicate Address Detection but is unclear on what to do when the same IP but different MAC (i.e., an actual IP address collision). Or is it covered in other documents? == NITS == -- Section 1 -- "BD and subnet are equivalent terms" while in the rest of the document "IP subnet" is often used. If "subnet IP" and "subnet" are synonyms, then I suggest to keep using one for consistency or at least mention that "IP subnet" and "subnet" are the same concept (or explain the difference if they are not identical). ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
