[bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-optimized-ir-09: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-optimized-ir-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/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-optimized-ir/



--
COMMENT:
--

Thank you to Derek Atkins for the SECDIR review.

** Section 10.   The following sentence doesn’t parse for me.  Can the guidance
on avoiding loops and the AR-REPLICATOR please be clarified.

   An implementation following the procedures in this document should
   not create BM loops, since the AR-REPLICATOR will always forward the
   BM traffic using the correct tunnel IP Destination Address that
   indicates the remote nodes how to forward the traffic.

** Section 10.  Editorial?

OLD
The forwarding of
   Broadcast and Multicast (BM) traffic is modified though, and BM
   traffic from …

NEW
The forwarding of Broadcast and Multicast (BM) traffic is modified; and BM
traffic from ...

** Section 10.  Typo. s/existance/existence/

** Editorial.  Multiple places.  Typo likely to rendering. s/section Section
X.X/Section X.X/



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] WGLC Request for draft-ietf-bess-bgp-sdwan-usage-04

[Linda Dunbar]

Matthew and Stephane,

We think the draft-ietf-bess-bgp-sdwan-usage-04 is ready for WGLC.
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/

The document demonstrates how the BGP-based control plane is used for 
large-scale SDWAN overlay networks with little manual intervention.
It is very useful for the industry.

Thank you,

Linda Dunbar

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] I-D Action: draft-ietf-bess-bgp-sdwan-usage-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : BGP Usage for SDWAN Overlay Networks
Authors : Linda Dunbar
  James Guichard
  Ali Sajassi
  John Drake
  Basil Najem
  David Carrel
Filename: draft-ietf-bess-bgp-sdwan-usage-04.txt
Pages   : 28
Date: 2021-10-18

Abstract:
   The document discusses the usage and applicability of BGP as the
   control plane for multiple SDWAN scenarios. The document aims to
   demonstrate how the BGP-based control plane is used for large-scale
   SDWAN overlay networks with little manual intervention.

   SDWAN edge nodes are commonly interconnected by multiple types of
   underlay networks owned and managed by different network providers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-bgp-sdwan-usage-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Lars Eggert's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS)

[Martin Vigoureux]

Hello Lars,

Le 2021-10-18 à 13:15, Lars Eggert via Datatracker a écrit :

Lars Eggert has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-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/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/



--
DISCUSS:
--

Entering a DISCUSS to make sure the authors respond to Paul Kyzivat's
Gen-ART review 
(https://mailarchive.ietf.org/arch/msg/gen-art/g5QZK_1U6boqzG8FjuJWhGG74RI),
and so that the IESG can discuss that review and (hopefully) any
responses to it.



Just in case.
Paul has sent the exact same review on v09.
At that time, the authors have replied and discussed the different 
points raised.

gen-...@ietf.org was copied on these e-mails.
The authors have made modifications to the document to tentatively 
address Paul's comments.


-m





___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [EXTERNAL] Lars Eggert's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS)

[Alexander Vainshtein]

Hi all,

I have done the RTG-DIR review of draft-ietf-bess-evpn-bum-procedure-updates-10 
(can be found 
here).

All the issues I have raised in my review have been resolved when the -11 
revision of the draft has been posted, and I have posted my confirmation of 
this 
fact.



After reading the DISCUSS, I have looked up the Gen-ART review, and I would 
like to provide a couple of comments.



  1.  I agree  with Paul (and noted this in my review as well) that "The draft 
is written in a very dense way"  specifically pointed to Section 5.1 that 
"contains just the deltas between the mechanisms already defined in RFC 7117 
and the mechanisms proposed in this draft" as an  example of the dense style. I 
have also noticed that "such style is quite valid to use" but "requires very 
good understanding of the "previous art" in order to understand this draft".  
At the same time I have said that "very good understanding of the "previous 
art""  is probably unavoidable in any case regardless of the style  - and in 
this my position differs from that of Paul.
  2.  I do not think that the draft updates RFC 7117 because it clearly and 
unequivocally (from my POV) states that it is only applicable to EVPN BUM 
procedures while RFC 7117 is only applicable to VPLS.  (The corresponding text 
is actually quoted verbatim in Paul's review, but somehow is considered there 
as further clouding things)
  3.  While I agree with Paul that the draft does not explicitly state in which 
way it updates RFC 7432, this is pretty much clear since it defines 3 new types 
of EVPN routes (on top of the types defined in RFC 7432 and some other 
documents) and defines how these routes are to be used. Looking up Section 8 
"IANA Considerations" should suffice IMHO
  4.  I also strongly disagree with Paul's position that this document should 
be re-written as RFC 7117bis - because the applicability scope of these two 
documents is mutually exclusive. As for making it RFC 7432 bis - the work on 
such a 
document 
has started, but it is in early stages. In particular, it does not address (as 
of this moment) any of the issues that the draft under consideration addresses, 
and I am not sure that simply including its content in a document that is 
already 67 pages long would really contribute to readability of any of these 
documents.



My comments above do not in any way replace the response of the authors 
requested by Lars. But hopefully they will still be useful.



Regards,

Sasha



Office: +972-39266302

Cell:  +972-549266302

Email:   alexander.vainsht...@rbbn.com



-Original Message-
From: BESS  On Behalf Of Lars Eggert via Datatracker
Sent: Monday, October 18, 2021 2:15 PM
To: The IESG 
Cc: zzhang_i...@hotmail.com; bess-cha...@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess@ietf.org
Subject: [EXTERNAL] [bess] Lars Eggert's Discuss on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS)



Lars Eggert has entered the following ballot position for

draft-ietf-bess-evpn-bum-procedure-updates-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://clicktime.symantec.com/3ERNe1NyWXsQHVSUvQ6ZVv6H2?u=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F

for more information about how to handle DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://clicktime.symantec.com/3Xy99bcsTf6XQ864fThDyjC6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-evpn-bum-procedure-updates%2F







--

DISCUSS:

--



Entering a DISCUSS to make sure the authors respond to Paul Kyzivat's Gen-ART 
review 
(https://clicktime.symantec.com/3JDNaatN3bgqjs6LpQVxS7i6H2?u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fgen-art%2Fg5QZK_1U6boqzG8FjuJWhGG74RI),

and so that the IESG can discuss that review and (hopefully) any responses to 
it.











___

BESS mailing list

BESS@ietf.org

https://clicktime.symantec.com/3AGkuPKSgGBrRRtordLC6Vg6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the 

Re: [bess] [Gen-art] Genart last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12

[Lars Eggert]

Matt, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2021-8-27, at 18:39, Matt Joras via Datatracker  wrote:
> 
> Reviewer: Matt Joras
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-bess-evpn-igmp-mld-proxy-??
> Reviewer: Matt Joras
> Review Date: 2021-08-26
> IETF LC End Date: 2021-09-07
> IESG Telechat date: Not scheduled for a telechat
> 
> Review
> 
>   Ethernet Virtual Private Network (EVPN) solution is becoming
>   pervasive in data center (DC) applications for Network Virtualization
>   Overlay (NVO) and DC interconnect (DCI) services, and in service
>   provider (SP) applications for next generation virtual private LAN
>   services.
> 
> This intro to the abstract could use some rewording. For example, "is 
> becoming"
> does not read well in a standards document. It is sufficient to describe what
> this document is specifying. Also "next generation" is overused and doesn't
> usually read well retrospectively.
> 
>   This draft describes how to support efficiently endpoints running
>   IGMP for the above services over an EVPN network by incorporating
>   IGMP proxy procedures on EVPN PEs.
> 
> Avoid using the term "draft" as this will have to be edited out since the idea
> is for this to be standards track.
> 
> 1.  Introduction
> 
>   Ethernet Virtual Private Network (EVPN) solution [RFC7432] is
>   becoming pervasive in data center (DC) applications for Network
>   Virtualization Overlay (NVO) and DC interconnect (DCI) services, and
>   in service provider (SP) applications for next generation virtual
>   private LAN services.
> 
> This is a copy of the abstract, and has similar issues. The introduction 
> serves
> a different purpose beyond the abstract, it also has the same grammatical
> issues as the abstract.
> 
>   In DC applications, a point of delivery (POD) can consist of a
>   collection of servers supported by several top of rack (TOR) and
>   Spine switches.  This collection of servers and switches are self
>   contained and may have their own control protocol for intra-POD
>   communication and orchestration.  However, EVPN is used as standard
>   way of inter-POD communication for both intra-DC and inter-DC.  A
>   subnet can span across multiple PODs and DCs.  EVPN provides robust
>   multi-tenant solution with extensive multi-homing capabilities to
>   stretch a subnet (VLAN) across multiple PODs and DCs.  There can be
>   many hosts/VMs(virtual machine) (several hundreds) attached to a
>   subnet that is stretched across several PODs and DCs.
> 
> Why is "Spine" capitalized? I'm also wondering whether another term might be
> appropriate here that doesn't imply a certain topology. Also,  "provides 
> robust
> multi-tenant solution" should probably be "provides a robust multi-tenant
> solution".
> 
>   These hosts/VMs express their interests in multicast groups on a
>   given subnet/VLAN by sending IGMP Membership Reports (Joins) for
>   their interested multicast group(s).  Furthermore, an IGMP router
>   periodically sends membership queries to find out if there are hosts
>   on that subnet that are still interested in receiving multicast
>   traffic for that group.  The IGMP/MLD Proxy solution described in
>   this draft accomplishes three objectives:
> 
> I don't think you need "/VMs". They are a kind of host. There is also another
> use of "draft" in this paragraph.
> 
>   3.  Selective Multicast: to forward multicast traffic over EVPN
>   network such that it only gets forwarded to the PEs that have
>   interest in the multicast group(s), multicast traffic will not be
>   forwarded to the PEs that have no receivers attached to them for
>   that multicast group.  This draft shows how this objective may be
>   achieved when Ingress Replication is used to distribute the
>   multicast traffic among the PEs.  Procedures for supporting
>   selective multicast using P2MP tunnels can be found in
>   [I-D.ietf-bess-evpn-bum-procedure-updates]
> 
> The first sentence is very long and could probably be reworded to be less
> redundant. Also there is another instance of "draft".
> 
>   The first two objectives are achieved by using IGMP/MLD proxy on the
>   PE and the third objective is achieved by setting up a multicast
>   tunnel (e.g., ingress replication) only among the PEs that have
>   interest in that multicast group(s) based on the trigger from IGMP/
>   MLD proxy processes.  The proposed solutions for each of these
>   objectives are discussed in the following sections.
> 
> The first sentence can probably be split into two. Also, is "(e.g., 

[bess] Lars Eggert's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-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/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-igmp-mld-proxy/



--
COMMENT:
--

"Abstract", paragraph 1, comment:
>This document describes how to support efficiently endpoints running
>IGMP for the above services over an EVPN network by incorporating
>IGMP proxy procedures on EVPN PEs.

It would be nice if acronyms were spelled out at least in the abstract (esp.
since it doesn't say where to go for further reading.) Also, "for the above
services"? Above where?

Section 9.4. , paragraph 6, comment:
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Type=0x06   |  Sub-Type=0x09|   Flags (2 Octets)  |M|I|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   Reserved=0  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The "Type" field is only seven bits long - that seems to be an error?

Section 9.5. , paragraph 20, comment:
>  1   2   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | Type=0x06   |  Sub-Type=n   |   RT associated with EVI  |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | RT associated with the EVI  (cont.) |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This diagram is only 31 bits wide?

You might want to use something like https://www.luismg.com/protocol/ to make
sure your header diagrams are accurate.

---
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 11. , paragraph 2, nit:
-provision to support IGMPv1.  There may be an implemention which is
+provision to support IGMPv1.  There may be an implementation which is
+   ++

Section 12. , paragraph 2, nit:
-TThis document does not add any new security considirattions, Same
-   ^  -
+ This document does not add any new security considerations, Same
+-  ^

"Table of Contents", paragraph 2, nit:
>  . . . . . . 18 9.2. Multicast Join Synch Route . . . . . . . . . . . . . . .
> ^
Do not mix variants of the same word ("synch" and "sync") within a single text.

"Table of Contents", paragraph 2, nit:
> on of servers and switches are self contained and may have their own control
>^^
This word is normally spelled with a hyphen.

Section 3. , paragraph 18, nit:
> triggering mechanism for the PEs to setup their underlay multicast tunnels.
> ^
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

Section 3. , paragraph 23, nit:
> sage at the recipient EVPN speaker. Thus it helps create an IGMP overlay subn
> 
A comma may be missing after the conjunctive/linking adverb "Thus".

Section 4.1.1. , paragraph 3, nit:
> et (and v2 reset). The IE flag also need to be set accordingly. Since source
> 
The verb form "need" does not seem to match the subject "flag".

Section 5. , paragraph 4, nit:
> with the v3 and exclude flag set. Finally when PE1 receives the IGMPv3 Join
>   ^^^
A comma may be missing after the conjunctive/linking adverb "Finally".

Section 5.2. , paragraph 2, nit:
> GMP Membership Report was received. Thus it MUST only be imported by the PEs
> 
A comma may be missing after the 

[bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke 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:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Zheng Zhang for his shepherd's write-up about the WG
consensus.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 3 --

It is a little unclear whether the first list of values are applicable to the
'route type' field. The reader can only guess when reading the pre-amble to the
2nd list.

-- Section 5.1 --
The text in this section appears to also update RFC 7117: "The following bullet
in Section 7.2.2.2 of [RFC7117]: ... s changed to the following when applied to
EVPN:". Should this document also formally update RFC 7117 ?



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Lars Eggert's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-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/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/



--
DISCUSS:
--

Entering a DISCUSS to make sure the authors respond to Paul Kyzivat's
Gen-ART review 
(https://mailarchive.ietf.org/arch/msg/gen-art/g5QZK_1U6boqzG8FjuJWhGG74RI),
and so that the IESG can discuss that review and (hopefully) any
responses to it.





___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-optimized-ir-09: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-optimized-ir-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/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-optimized-ir/



--
COMMENT:
--

Thank you for the work put into this document.

Please reply and address the points raised by Pascal Thubert (thank you
Pascal!) in his internet directorate review at:
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-optimized-ir-09-intdir-telechat-thubert-2021-10-15/
or at https://mailarchive.ietf.org/arch/msg/bess/qLMMP2d49xjKy_JXNCUo1DBOwVs/

With Pascal's review, I have only skimmed the document and have only 1 nit:
please introduce references to IR/EVPN/PIM early in the text.

I also wonder why the specific case of NVO is discussed in the document as I
would assume that the issues are in all EVPN deployments.

Pascal and I hope that this helps to improve the document,

Regards,

-éric



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess