Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)
Hi John, The duplication itself is a problem - a receiver should not receive duplicates. However, a source should not send the same packet to two BDs. That's what the paragraph is supposing: ... (This does assume that source S does not send the same (S,G) datagram on two different BDs ...) Thanks. Jeffrey Juniper Business Use Only -Original Message- From: John Scudder Sent: Thursday, March 7, 2024 11:07 AM To: Jeffrey (Zhaohui) Zhang Cc: The IESG ; draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; manka...@cisco.com Subject: Re: John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT) On Mar 7, 2024, at 9:47 AM, Jeffrey (Zhaohui) Zhang wrote: > > zzh> If the source host is also connected to another BD3 that is attached to > PE2 and it is sending to both BD2 and BD3, then both copies will be switched > to PE1 via the SBD So the only consequence is suboptimality because of duplicated packets? That seems fine. Thanks. —John ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)
On Mar 7, 2024, at 9:47 AM, Jeffrey (Zhaohui) Zhang wrote: > > zzh> If the source host is also connected to another BD3 that is attached to > PE2 and it is sending to both BD2 and BD3, then both copies will be switched > to PE1 via the SBD So the only consequence is suboptimality because of duplicated packets? That seems fine. Thanks. —John ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04
I support this document for WG adoption. I'm not aware of any related undisclosed IPR. From: Jeffrey (Zhaohui) Zhang Date: Wednesday, March 6, 2024 at 1:32 PM To: 'BESS' , draft-sr-bess-evpn-dp...@ietf.org Cc: idr@ietf. org , 'bess-cha...@ietf.org' Subject: WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04 Hi, This email begins a two-week WG adoption and IPR poll for draft-sr-bess-evpn-dpath-04 (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sr-bess-evpn-dpath/__;!!CQl3mcHX2A!CPIG4lPFvBpZCs2tVSCK7hLZjfDKnvRLnSe9uhz4xTHMZOw1tJkdwm2kZ5g4X9Ea4lRKA4vAXBc5r1S7$ ). Please review the draft and post any comments to the BESS working group list. The IDR list is copied in this call because of the Domain Path Attribute (D-PATH) introduced in draft-ietf-bess-evpn-ipvpn-interworking. We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document will not progress without answers from all the authors and contributors. If you are not listed as an author or a contributor, then please explicitly respond to the IPR poll only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 20th March 2024. Thanks. BESS chairs Juniper Business Use Only ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] [Errata Held for Document Update] RFC8214 (7837)
The following errata report has been held for document update
for RFC8214, "Virtual Private Wire Service Support in Ethernet VPN".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7837
--
Status: Held for Document Update
Type: Technical
Reported by: Alexander ("Sasha") Vainshtein
Date Reported: 2024-03-05
Held by: John Scudder (IESG)
Section: 3.1
Original Text
-
This document defines a new extended community [RFC4360], to be included with
per-EVI Ethernet A-D routes. This attribute is mandatory if multihoming is
enabled.
Corrected Text
--
This document defines a new extended community [RFC4360], to be included with
per-EVI Ethernet A-D routes.
If multihoming is enabled, this attribute is MANDATORY regardless of whether
the per-EVI Ethernet A-D route is advertised by an EVPN-VPWS instance or by a
"bridging" EVPN instance.
Notes
-
The lower-case "mandatory" used in the original text does not represent any
form of requirement in IETF documents, therefore replacing with upper-case
"MANDATORY" is needed.
The reference to per-EVI Ethernet A-D routes advertised by both "bridging" EVPN
and EVPN-VPWS is needed to remove possible doubts about the scope of this
requirement since the standard is about EVPN-VPWS.
--
Verifier note: see also
https://mailarchive.ietf.org/arch/msg/bess/vBYU98CJkLvHfvnX_6wIsV2cCFM/
--
RFC8214 (draft-ietf-bess-evpn-vpws-14)
--
Title : Virtual Private Wire Service Support in Ethernet VPN
Publication Date: August 2017
Author(s) : S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan
Category: PROPOSED STANDARD
Source : BGP Enabled ServiceS
Area: Routing
Stream : IETF
Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)
Hi John, Thank you for your review and comments. A new revision will be posted after the pre-IETF119 quiescence period. Please see zzh> below. -Original Message- From: John Scudder via Datatracker Sent: Wednesday, March 6, 2024 8:08 PM To: The IESG Cc: draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; manka...@cisco.com; manka...@cisco.com Subject: John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT) [External Email. Be cautious of content] John Scudder has entered the following ballot position for draft-ietf-bess-evpn-irb-mcast-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!A78Ta3ONdPXEoLQIN_Gt40k6a96liTui1TPt4pd7phW8_rrv8UPDH6pB3ufNR90lr3bDTnxSm3NQbOQ$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!A78Ta3ONdPXEoLQIN_Gt40k6a96liTui1TPt4pd7phW8_rrv8UPDH6pB3ufNR90lr3bDTnxSbovfttY$ -- COMMENT: -- Thanks for this document. Although dense and slow going, I appreciated the thoroughness and precision and have confidence that the dedicated reader who makes it all the way through will be able to implement this specification. I have some minor comments below that I hope might be of use. - I continue to find the profligate use of acronyms and initialisms that characterizes so many bess documents to be an unnecessary, not to say gratuitous, impediment to readability, but so it goes. (If the authors are open to what might be an extensive revision to address this, I'm willing to dig in and provide more detailed feedback. But I don't expect it, at this late stage, especially since as noted above, I do think the document is usable, my complaint notwithstanding. If I'm mistaken, let me know and we can work on it.) Zzh> Let me work with you separately on addressing this problem going forward in general. - I agree with Éric Vyncke that there are several places where the text could easily be elucidated with the use of a diagram. Essentially, any of the many (very welcome!) examples seems like an easy candidate, one instance being “Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches to BD2 and BD3.” Zzh> I added the following for the example you give: SBDSBD / \ /\ +---+ +---+ |PE1+--+PE2| +---+ +---+ | \ / | BD1 BD2 BD2 BD3 Zzh> I had to change the format of this email from plain text and use Courier New font. Hopefully it comes out aligned. - I'm sure the RFCEd will flag this, but consider replacing the pronoun "he" in Section 1.3 with something not gender-specific. Zzh> I changed it to “it”. I suppose we can use “it” for a “tenant” because we’re talking about an organization not a person. - In Section 1.5.2 you mention an “attachment AC”, which expands as "attachment attachment circuit". Probably drop "attachment" or (better still in my view, see my first bullet) spell out "attachment circuit". Zzh> I spelled it out. - In Section 2.5 you have “This does assume that source S does not send the same (S,G) datagram on two different BDs, and that the Tenant Domain does not contain two or more sources with the same IP address S. The use of multicast sources that have IP "anycast" addresses is outside the scope of this document?” I tried to puzzle out what the consequence would be if that situation arose, but failed. Can you comment? Zzh> Let me quote the context below. If all the sources and receivers for a given (*,G) are in the Tenant Domain, inter-subnet "Any Source Multicast" traffic will be properly routed without requiring any Rendezvous Points, shared trees, or other complex aspects of multicast routing infrastructure. Suppose, for example, that: * PE1 has a local receiver, on BD1, for (*,G) * PE2 has a local source, on BD2, for (*,G). PE1 will originate an SMET(*,G) route for the SBD, and PE2 will receive that route, even if PE2 is not attached to BD1. PE2 will thus know to forward (S,G) traffic to PE1. PE1 does not need to do any "source discovery". (This does
Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)
Thanks, Rob. I have changed that. A new revision with some other minor changes will be posted after the pre-IETF119 quiescence period. Jeffrey Juniper Business Use Only -Original Message- From: Robert Wilton via Datatracker Sent: Thursday, March 7, 2024 6:34 AM To: The IESG Cc: draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; manka...@cisco.com; manka...@cisco.com Subject: Robert Wilton's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT) [External Email. Be cautious of content] Robert Wilton has entered the following ballot position for draft-ietf-bess-evpn-irb-mcast-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!AHYVKqdnIFS8Z1fiig5zR8V9MFgDfNSMs7auANZ0yhJzJbWFww-Ah7AiKw21r9pa9foq6LyB4t8Q1nI$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!AHYVKqdnIFS8Z1fiig5zR8V9MFgDfNSMs7auANZ0yhJzJbWFww-Ah7AiKw21r9pa9foq6LyBcyvcBqs$ -- COMMENT: -- Hi, One minor comment to check: (1) p 10, sec 1.3. Need for EVPN-aware Multicast Procedures However, that technique does not provide optimal routing for multicast. In conventional multicast routing, for a given multicast flow, there is only one multicast router on each BD that is permitted to send traffic of that flow to the BD. If that BD has receivers for a given flow, but the source of the flow is not on that BD, then the flow must pass through that multicast router. This leads to the "hair-pinning" problem described (for unicast) in Appendix A. For example, consider an (S,G) flow that is sourced by a TS S and needs to be received by TSes R1 and R2. Suppose S is on a segment of BD1, R1 is on a segment of BD2, but both are attached to PE1. Suppose also that the tenant has a multicast router, attached to a segment of BD1 and to a segment of BD2. However, the segments to which that router is attached are both attached to PE2. Then the flow from S to R would have to follow the path: S-->PE1-->PE2-->Tenant Multicast Router-->PE2-->PE1-->R1. Obviously, the path S-->PE1-->R would be preferred. S to R => S to R1, and PE1-->R to PE1-->R1? Regards, Rob ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04
As a co-author, I support this document for WG adoption. I'm not aware of any related undisclosed IPR. Thanks, Mallika -Original Message- From: Jeffrey (Zhaohui) Zhang Sent: Wednesday, March 6, 2024 10:32 AM To: 'BESS' ; draft-sr-bess-evpn-dp...@ietf.org Cc: idr@ietf. org ; 'bess-cha...@ietf.org' Subject: WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi, This email begins a two-week WG adoption and IPR poll for draft-sr-bess-evpn-dpath-04 (https://datatracker.ietf.org/doc/draft-sr-bess-evpn-dpath/). Please review the draft and post any comments to the BESS working group list. The IDR list is copied in this call because of the Domain Path Attribute (D-PATH) introduced in draft-ietf-bess-evpn-ipvpn-interworking. We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document will not progress without answers from all the authors and contributors. If you are not listed as an author or a contributor, then please explicitly respond to the IPR poll only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 20th March 2024. Thanks. BESS chairs Juniper Business Use Only ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-bess-evpn-irb-mcast-11: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/ -- COMMENT: -- Hi, One minor comment to check: (1) p 10, sec 1.3. Need for EVPN-aware Multicast Procedures However, that technique does not provide optimal routing for multicast. In conventional multicast routing, for a given multicast flow, there is only one multicast router on each BD that is permitted to send traffic of that flow to the BD. If that BD has receivers for a given flow, but the source of the flow is not on that BD, then the flow must pass through that multicast router. This leads to the "hair-pinning" problem described (for unicast) in Appendix A. For example, consider an (S,G) flow that is sourced by a TS S and needs to be received by TSes R1 and R2. Suppose S is on a segment of BD1, R1 is on a segment of BD2, but both are attached to PE1. Suppose also that the tenant has a multicast router, attached to a segment of BD1 and to a segment of BD2. However, the segments to which that router is attached are both attached to PE2. Then the flow from S to R would have to follow the path: S-->PE1-->PE2-->Tenant Multicast Router-->PE2-->PE1-->R1. Obviously, the path S-->PE1-->R would be preferred. S to R => S to R1, and PE1-->R to PE1-->R1? Regards, Rob ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
