[bess] Warren Kumari's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-mvpn-evpn-aggregation-label-13: 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-mvpn-evpn-aggregation-label/ -- COMMENT: -- Thank you for this document, and for working to address Menachem Dodge's OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-bess-mvpn-evpn-aggregation-label-10-opsdir-lc-dodge-2023-07-02/ ) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-bgp-sdwan-usage-15: (with COMMENT)
Warren Kumari has entered the following ballot position for
draft-ietf-bess-bgp-sdwan-usage-15: 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-bgp-sdwan-usage/
--
COMMENT:
--
I am balloting NoObjection, but am quite uncomfortable with it -- I will steal
some of Eric V's ballot text - "... I find it ***weak*** on several points (see
below) and more accurate language will be welcome rather than hand waving. I
strongly suggest that the authors/WG have a second pass on the document."
The document is very hand-wavey, and, based on the number of open comments and
nits, does not appear to have had significant detailed review; I almost
balloted DISCUSS because of this.
This document would benefit from copy-editing.
1: The document opens with: "Here are some of the main characteristics of
"SD-WAN" networks: [...]"
-- I don't really think that most of these are "the main characteristics of
"SD-WAN" networks" - e.g: "Instead of all traffic hauled to Corporate HQ for
centralized policy control, direct Internet breakout from remote branch
offices is allowed." - this is a characteristic of many many different
technologies and VPN solutions. The implication of this sentence so early in
the document is that a: these are differentiating characteristics, and b: that
they are the **main** characteristics.
2: Editorial: "Instead of all traffic hauled to Corporate HQ for centralized
policy control, direct Internet breakout from remote branch offices is
allowed." - "Instead of hauling all traffic to ..." or "Instead of having all
traffic hauled to..." or...
3: "Some traffic can be forwarded by edge nodes, based on their application
identifiers instead of destination IP addresses, by placing the traffic onto
specific overlay paths based on the application-specific policies." - the
subject of this sentence is very unclear. What is this "some traffic" (why not
all? what does "some" do in this sentence?). Same for "their" in "their
application identifiers".
4: "CPE-Based VPN: Virtual Private Secure network formed among CPEs. This
differentiates from more commonly used PE-based VPNs". How does "VPN" expand to
"Virtual Private Secure network"? **How** this this "differentiates" from more
commonly used PE-based VPNs? ("This differs from more commonly used PE-based
VPNs as it is formed between CPE" would sort of work, but it is still very
unclear *why* this is being noted.
5: "SD-WAN: Software Defined Wide Area Network is an overlay network ..." -
this is a much better definition than how the document was opened. I suggest
that it be used if you want to introduce what SD-WAN **is**.
6: "Conventions used in this document [...] SD-WAN over Hybrid Networks: SD-WAN
over Hybrid Networks typically have edge nodes... You never actually use that
term - you *do* use Hybrid Underlay (e.g "SD-WAN with Hybrid Underlays") a
bunch of times though.
7: "For multicast packets forwarding" -> "For multicast packet forwarding"
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-pbb-evpn-isid-cmacflush-08: 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-pbb-evpn-isid-cmacflush/ -- COMMENT: -- I fully agree with Eric's "This is a very specific area of work and the text is not easy to read for a non expert. I read it, but was somewhat baffled by the quantity of acronyms and terminology, and to I too relied on Pascal Thubert's IntDir review (https://datatracker.ietf.org/doc/review-ietf-bess-pbb-evpn-isid-cmacflush-08-intdir-telechat-thubert-2023-08-07/) to help choose my position. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-pref-df-11: 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/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-pref-df/ -- DISCUSS: -- Why are there two algorithms (Highest-Preference and Lowest-Preference)?[0] This seems operationally dangerous and will lead to additional operational complexity, tricky to debug behaviors, additional implementation complexity, etc. Assuming that there *is* a good reason (and "Well, we couldn't decide,, so... ¯\_(ツ)_/¯" isn't one) these should be a section helping operators decide which algorithm they should deploy, and the pro's and con's of each. [0]: I did try and find this, but the closest I got was a note in the Shepherd Writeup saying: "There was a "last minute" agreement on managing the highest/lowest pref algorithm using different DF algs rather than a single one+local configs." -- this doesn't actually answer the question. -- COMMENT: -- I support John Scudder's DISCUSS, as well as his comments -- the Introduction seems quite incomplete, and just sort of throws the reader into the deep end. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-virtual-eth-segment-11: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-virtual-eth-segment-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-virtual-eth-segment/ -- COMMENT: -- Thank you to the authors for addressing my DISCUSS position so quickly and painlessly! Also, thank you very much for writing this document. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-virtual-eth-segment-10: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-virtual-eth-segment-10: 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/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-virtual-eth-segment/
--
DISCUSS:
--
Be ye not afraid - this DISCUSS should be easy to address.
Please see
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for some information on DISCUSS ballots
Like Paul Wouters I find Section 9 ("Intellectual Property Considerations")
troubling, but I'm sufficiently troubled that I feel it deserves a DISCUSS. I
*think* that what the text says is compatible with what is in BCP79 / the
copyright boilerplate, but: 1: IANAL and 2: if it's exactly the same, why is
this section here?
If it *not* the same, then I think that this requires some discussions with the
IETF Trust / lawyers / etc...
I strongly suggest removing it, or, if it is needed for some sort of corporate
/ legal reason that it be justified / explained.
--
COMMENT:
--
Thank you very much for writing this document.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-lsp-ping-09: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-lsp-ping-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/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-lsp-ping/ -- COMMENT: -- Like Roman, I support the DISCUSS positions of Jim Guichard and Lars Eggert. I'd also like to thank Di Ma for the DNS-DIR review. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's Abstain on draft-ietf-bess-srv6-services-12: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-srv6-services-12: Abstain 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-srv6-services/ -- COMMENT: -- With the updated text in the Security Considerations in Version 12, I'm clearing my DISCUSS. I still don't love this (hence the Abstain), but my disquiet is caused caused by the security considerations in SRv6, not this document itself. I'd like to specifically call out and thank Ketan Talaulikar, who did an outstanding job at communicating, addressing the concerns, and defusing the situation in general. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-srv6-services-10: 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/blog/handling-iesg-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-srv6-services/ -- DISCUSS: -- The Security Considerations section says: "The service flows between PE routers using SRv6 SIDs advertised via BGP are expected to be limited within the trusted SR domain (e.g., within a single AS or between multiple ASes within a single provider network). Precaution should be taken to ensure that the BGP service information (including associated SRv6 SID) advertised via BGP sessions are limited to peers within this trusted SR domain." This is related to (from RFC8402): "Therefore, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain." However, we all know that BGP leaks happen -- and when they do, the SID’s contained in the leak will be logged by various systems and hence available to the public into perpetuity. While the document states that border filtering should protect against traffic injection, this does not cover the case of internal compromise. Sure, there is the argument that once there is an internally compromised system, all bets are off -- but with this, an attacker that knows the SIDs in e.g inject traffic into a VPN. This seems to me to significantly expand the attack surface to include the customer's networks too. Not only does an operator have to ensure that BGP leaks never occur, they have to then ensure that at no point can there be any filter lapses at any border node, and be able to guarantee the security of every device, server and machine within the domain in order for a secure posture to be maintained. Simply saying that precautions should be taken to make sure that route leak don't occur, when the consequences of doing so are a: severe and b: hard to recover from seems to not really cover it. In addition, it seems that the blast radius from a missing ACL seems much larger if it allows injections. -- COMMENT: -- I'm still reviewing the document, but wanted to get an initial ballot in, so that we could start discussing it. Hopefully someone can help my understand how this doesn't expand the consequences of a BGP leak. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-bum-procedure-updates-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/blog/handling-iesg-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-bum-procedure-updates/ -- COMMENT: -- Much thanks to Scott Bradner for the OpsDir review (-09), discussions and then re-review of -11. Jeffrey has agreed to change the SHOULD at the ned of S5.3.1 to a MUST (see OpsDir thread), and I'm balloting NoObj with the assumption that that will happen. Thanks again to Scott and the authors; I think that the comments since -09 have noticeably improved the document. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-datacenter-gateway-11: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-datacenter-gateway-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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/ -- COMMENT: -- I am changing my previous DISCUSS to a No Objection; I was planning on Abstain, but after yet more thought I think No Objection is the best position. Background: When thinking about this document I still feel disquiet (actually "heebie-jeebies" is probably a better description!), but it's not actually **this** document which is causing me concern, it is rather RFC8402 (and the fact that this facilitates /propagates its use). I still feel like stamping my feet and throwing all of my toys out the cot, but my grump cannot realistically be pointed at this draft. I'd also like to recognize that Adrian Farrel did a great job on talking me down from my ledge. I was filled with righteous indignation, and his helpful and friendly tone helped me understand and process my thoughts; this directly led to my willingness to change. Thank you everyone. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS)
Warren Kumari has entered the following ballot position for draft-ietf-bess-datacenter-gateway-10: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/ -- DISCUSS: -- I hope that I'm just misunderstanding something obvious, but I strongly support John's DISCUSS -- when SR was "approved" it was with the understanding that it would only be used within "real" limited domains, and would never be sent outside of closed/limited network. The document says: "The solution defined in this document can be seen in the broader context of SR domain interconnection in [I-D.farrel-spring-sr-domain-interconnect]. ", which says: " Traffic originating in one SR domain often terminates in another SR domain, but must transit a backbone network that provides interconnection between those domains." -- is it unclear to me if this is really what is being proposed... I'm hoping that I'm really misunderstanding something here -- please educate me. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-proxy-arp-nd-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/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-proxy-arp-nd/ -- COMMENT: -- Thank you for engaging with, and addressing the OpsDir review, and thanks to Joe for performing it... ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-na-flags-08: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-na-flags-08: 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-na-flags/ -- COMMENT: -- [ Update: Thank you for addressing my DISCUSS concern. ] Other than my DISUCSSes, I found this document to be well written and easy to understand - thank you for writing it... ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-na-flags-06: 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-na-flags/ -- DISCUSS: -- Be ye not afraid! This DISCUSS should be fairly trivial to address... This allows for more information to be carried with MAC/IP Advertisements. It seems to me that this gives a DoS-style attacker more opportunities to exhaust state on routers - I could sit on a wire and create lots of ARP/ND states (make up new IP and MAC combinations), causing this to be propagated and burning memory / state / etc. This is somewhat discussed in RFC 7432, but the technique in this document seems like it makes this issue somewhat worse - a single sentence in the Security Considerations noting it would satisfy me (as would an explanation that I'm mistaken :-)). I also support EK & Rob's DISCUSSes -- COMMENT: -- Other than my DISUCSSes, I found this document to be well written and easy to understand - thank you for writing it... ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Warren Kumari's No Objection on draft-ietf-bess-rfc5549revision-04: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-bess-rfc5549revision-04: 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-rfc5549revision/ -- COMMENT: -- I found this document really hard to review - not because the document itself was unclear, but rather because I had to keep going back and forth between it and RFC5549. Passing it though 'diff' helped some, but a few sentences explaining the differences would have helped immensely; it would also help RFC5549 implementers understand what they need to change to be compliant... ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
