The document has a good level of support to progress. However there are several
comments raised that have not been answered yet.
Authors,
Could you please address the comments that have been raised on the list (from
Acee, Krysztof, and Luc Andre) ?
Thanks,
Stephane
From: BESS [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, August 08, 2018 16:04
To: [email protected]
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05
Hello working group,
This email starts a two-week Working Group Last Call on
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].
A significant amount of update has been introduced since the previous WGLC.
Please review the updates and provide your feedback.
This poll runs until *the 22th of August*.
Thank you
Stéphane, Matthew
bess chairs
[1]
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
--- Begin Message ---
Support.
This is an important draft and is implemented;
(1) I echo Acee's comment re: "Router MAC" for readability
(2) The document often refers to two Route-targets (MAC-VRF & IP-VRF) which is
overly restrictive.
I would propose language more to the effect of MAC/IP must be advertised with
two sets of RTs
RFC7432: EVPN route MAY carry one or more Route Target (RT) attributes.
vs. for example:
This route MUST be advertised with two route targets - one
corresponding to the MAC-VRF of the tenant's subnet and another
corresponding to the tenant's IP-VRF.
Thanks,
Luc André Burdet
_____
From: BESS <[email protected]> on behalf of [email protected]
<[email protected]>
Sent: August 8, 2018 10:03 AM
To: [email protected]
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05
Hello working group,
This email starts a two-week Working Group Last Call on
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].
A significant amount of update has been introduced since the previous WGLC.
Please review the updates and provide your feedback.
This poll runs until *the 22th of August*.
Thank you
Stéphane, Matthew
bess chairs
[1]
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
--- End Message ---
--- Begin Message ---
Hello working group,
I have two comments regarding section 3.1.
* Section 3.1. refers only to “ARP” or “ARP reply”. Given the fact, it is
applicable to IPv6 as well, it should refer to ND NS/NA messages as well, I
believe.
* In the last paragraph of Section 3.1:
> Irrespective of using only the anycast address or both anycast and
non-anycast addresses on the same IRB, when a TS sends an ARP request
to the PE that is attached to, the ARP request is sent for the
anycast IP address of the IRB interface associated with the TS's
subnet.
If both anycast and non-anycast addresses are on the IRB, it is legitimate that
TS sends NS/ARP request to resolve either anycast (e.g. to resolve IP address
of default gateway configured on TS), or to resolve non-anycast (e.g. ping
towards non-anycast address was initiated on TS). Therefore, presuming that TS
sends ARP request to resolve only anycast IP is not fully correct, I believe.
Thus, wording of this paragraph should cover two cases (NS/ARP request to
resolve anycast, and NS/ARP request to resolve non-anycast IP).
>> the PE1 sends an ARP reply with the MACx which is the anycast
MAC address of that IRB interface.
NA/ARP reply has multiple MAC related fields:
* Destination MAC (in Ethernet header)
* Source MAC (in Ethernet header)
* Sender hardware address (in the payload)
* Target hardware address (in the payload)
It is not ultimately clear from the text, if 'Source MAC (in Ethernet header)’
or 'Sender hardware address (in the payload)’, or both, should be populated
with MACx. As I see it, in case of both anycast and non-anycast address is used
on IRB, the behavior should be:
* TS sends and NS/ARP request for the anycast address:
-> PE sends and NA/ARP reply with anycast MAC in both 'Source MAC (in
Ethernet header)’ and 'Sender hardware address (in the payload)’ fields
* TS sends and NS/ARP request for the non-anycast address:
-> PE sends and NA/ARP reply with non-anycast MAC in both 'Source MAC (in
Ethernet header)’ and 'Sender hardware address (in the payload)’ fields
Otherwise, if only 'Sender hardware address (in the payload)’ is populated with
anycast/non-anycast MAC (depending, which IP address is being resolved), and
'Source MAC (in Ethernet header)’ is always populated with no-anycast MAC (in
implementations mimicking RFC 5798, Section 8.1.2/8.2.2/8.2.3 behavior, which
explicitly disables usage of V-MAC in the 'Source MAC (in Ethernet header)’),
the L2 domain (L2 switches) between PE and CE will not learn anycast MAC, thus
resulting in unknown unicast flooding being used on these switches to reach
anycast MAC. This is undesirable behavior and should be avoided.
Thanks,
Krzysztof
On 2018-Aug-08, at 16:03,
[email protected]<mailto:[email protected]> wrote:
Hello working group,
This email starts a two-week Working Group Last Call on
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].
A significant amount of update has been introduced since the previous WGLC.
Please review the updates and provide your feedback.
This poll runs until *the 22th of August*.
Thank you
Stéphane, Matthew
bess chairs
[1]
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess
--- End Message ---
--- Begin Message ---
Hi Stephane, Authors,
I support advancement. This is a useful optimization that has been implemented .
Two comments:
1. Call the new BGP Community “Router MAC” rather than “Router’s MAC”.
2. Consistently use “TSes” to refer to multiple Tenant Systems and “TS’s”
to refer to an address or other entity processed by a Tenant System.
I have some other editorial comments that I will pass to the authors.
Thanks,
Acee
From: BESS <[email protected]> on behalf of Stephane Litkowski
<[email protected]>
Date: Wednesday, August 8, 2018 at 10:03 AM
To: "[email protected]" <[email protected]>
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05
Hello working group,
This email starts a two-week Working Group Last Call on
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].
A significant amount of update has been introduced since the previous WGLC.
Please review the updates and provide your feedback.
This poll runs until *the 22th of August*.
Thank you
Stéphane, Matthew
bess chairs
[1]
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
--- End Message ---
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
