[bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk 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:
--

I'm not sure whether the Leaf A-D route (route type specific field) as
specified by this document is guaranteed to have a unique
interpretation (§3.3).  It's supposed to start with the "route key",
which is just the route-type-specific field of the PMSI route that
triggered the Leaf A-D route.  That makes the route key variable length
(as stated), and this variation is clearly achieved given that even the
Per-Region I-PMSI A-D route and S-PMSI A-D route defined in this
document have different length and layout.  I'm not sure what
information is expected to be available to bound and determine the
length of this "route key" field, other than "not the rest of the
stuff".  "The rest of the stuff" is the originator's address and length
thereof, but the length is in the middle of the structure, so even if we
start parsing from the back we still can't distinguish reliably between
a 4-byte IPv4 address and a 16-byte IPv6 address.  It seems that the
Originator's Addr Length would need to be the last field in order to
provide a unique interpretation, with "parse backwards" used to extract
the Originator's Address, and "the rest of the stuff" being the route
key that can be matched to the triggering PMSI route.  Is there some
other procedure or contextual information available that ensurs a unique
interpretation of this data?  Looking at RFCs 6514 and 7117, it does not
seem like this document has some key change that renders it
fundamentally different in this regard, so I mostly assume that the
received route can be disambiguated somehow; I just don't know what that
way is.


--
COMMENT:
--

Section 1

   It is expected that audience is familiar with EVPN and MVPN concepts
   and terminologies.  For convenience, the following terms are briefly

Please provide references for EVPN and MVPN that would serve as entry
points for gaining such familiarity.  E.g., RFCs 7432 and 6513/6514.

   explained.

I suggest including PMSI Tunnel Attribute in this list, especially since
RFC 6514 does not actually use the PTA acronym.

Section 2.1

   There is a difference between MVPN and VPLS multicast inter-as
   segmentation.  For simplicity, EVPN will use the same procedures as
   in MVPN.  All ASBRs can re-advertise their choice of the best route.

While it is defensible to rely on the stated expectation that the reader
is familiar with EVPN and MVPN concepts (hmm, which does not actually
include VPLS concepts?), it would be appreciated to include some
indication of the nature of the difference, before stating which variant
EVPN will use.

   For inter-area segmentation, [RFC7524] requires the use of Inter-area
   P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting
   of "Leaf Information Required" L flag in PTA in certain situations.
   Either of these could be optional in case of EVPN.  Removing these

"Could be"?  It sometimes is and sometimes isn't?  When is it still
mandatory?

Section 2.1.1

   For example, an MVPN/VPLS/EVPN network may span multiple providers
   and Inter-AS Option-B has to be used, in which the end-to-end

Is this "option (b)" of §7.2 of RFC 7117?  Regardless, a specific
reference seems in order.

   Another advantage of the smaller region is smaller BIER sub-domains.
   In this new multicast architecture BIER [RFC8279], packets carry a

RFC 8279 was published just about four years ago.  Does that still
qualify as "new"?  (I honestly am not sure, given the distribution of
time from -00 to RFC.)

Section 3

   The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs
   starts with a type 1 RD, whose Administrator sub-field MUST match
   that of the RD in all non-Leaf A-D (Section 3.3) EVPN routes from the
   same advertising router for a given EVI.

Is the requirement really so specific as "everything except Leaf A-D"?
What if some new type is allocated that also doesn't start with an RD?
Is it safe to say that any type that does have an RD must meet this
criterion?

Section 4

   The optional optimizations specified for MVPN in [RFC8534] are also
   applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are

[bess] John Scudder's Discuss on draft-ietf-bess-evpn-optimized-ir-09: (with DISCUSS and COMMENT)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-optimized-ir-09: 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-optimized-ir/



--
DISCUSS:
--

DISCUSS:

In my review there are a number of comments/questions that I would like
to be sure of having discussed. In particular, the questions about use
of SHOULD without associated discussion of exception cases.  I would
also like to be make sure the question about whether non-BM receivers
are, or are not, excluded from flood lists (§6.1) has been addressed.

Of course I would also appreciate replies to my other comments! :-)


--
COMMENT:
--

Overall comments:

1. This document suffers from what I think is an overuse of
   abbreviations.  See
   
https://www.psychologicalscience.org/observer/alienating-the-audience-how-abbreviations-hamper-scientific-communication
   for one perspective on why this is problematic.  Any individual one of these
   doesn't rise to the level of being objectionable, but in aggregate at some
   point it makes the document a lot less accessible to anyone who isn't part
   the in-group who has memorized the abbreviations. 4r xm, <- ... is !@? to
   rd, 4r no gd rn, [see terminology section below] even though anyone who goes
   to the effort of looking up the terminology can decode it.  I would really
   prefer it if this were improved; I think it's not that much work for the
   authors and will make the resulting spec more usable.  I had intended to
   offer an example edit that expands many of the abbreviations, but have run
   out of time; I'd still be willing to do it later if requested, let me know.

   (Consider also the contrast with RFC 6514; for instance instead of
   referring to "the L-flag", when mentioning that flag it says "the Leaf
   Information Required flag".  Since we don't pay by the byte for publishing
   our documents, it seems to be worth spending a few more keystrokes to
   make it easier to read them.)

2. The document starts in the middle.  It jumps right from the requirements
   to the tunnel attribute diagram, with no overview or outline of the
   solution.  This is related to Pascal's review comment, mentioned by Éric
   Vyncke.

Terminology:

   4r: for
   xm: example
   <-: this
   ...: sentence
   !@?: difficult
   rd: read
   gd: good
   rn: reason

Detailed review:

I’ve done my comments in the form of an edited copy of the draft.  I
don't think the datatracker tooling allows me to use attachments, so
I'll follow up to this with an email with attached edited copy, as well
as a PDF of the rfcdiff output for your convenience if you’d like to use
it. I’ve also pasted a traditional diff below to capture the comments
for the record and in case you want to use it for in-line reply. I’d
appreciate feedback regarding whether you found this a useful way to
receive my comments as compared to a more traditional numbered list of
comments with selective quotation from the draft.

*** draft-ietf-bess-evpn-optimized-ir-09.txt2021-10-20 13:48:15.0
-0400 --- draft-ietf-bess-evpn-optimized-ir-09-jgs-markup.txt 2021-10-20
20:39:39.0 -0400
***
*** 19,25 

  Abstract

!Network Virtualization Overlay (NVO) networks using EVPN as control
 plane may use Ingress Replication (IR) or PIM (Protocol Independent
 Multicast) based trees to convey the overlay Broadcast, Unknown
 unicast and Multicast (BUM) traffic.  PIM provides an efficient
--- 19,25 

  Abstract

!Network Virtualization Overlay (NVO) networks using EVPN as their control
 plane may use Ingress Replication (IR) or PIM (Protocol Independent
 Multicast) based trees to convey the overlay Broadcast, Unknown
 unicast and Multicast (BUM) traffic.  PIM provides an efficient
***
*** 105,111 

 Ethernet Virtual Private Networks (EVPN) may be used as the control
 plane for a Network Virtualization Overlay (NVO) network.  Network
!Virtualization Edge (NVE) devices and Provider Edges (PEs) that are

--- 105,111 

 Ethernet Virtual Private Networks (EVPN) may be used as the control
 plane for a Network Virtualization Overlay (NVO) network.  Network
!Virtualization Edge (NVE) and Provider Edge (PEs) devices that are

***
*** 182,187 
--- 182,191 
  

[bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-13: 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-igmp-mld-proxy/



--
DISCUSS:
--

(1) Apparently each PE is supposed to store version flags for each other PE
in the EVI (I guess on a per-route basis?), but this is mentioned just
once, in passing, in step 2 of the Leave Group procedures in §4.1.2.
Similarly, §6.1 defines, somewhat in passing, some "local IGMP
Membership Request (x,G) state" that must be maintained in some cases.
Let's discuss whether it's appropriate/useful to have a general introductory
section that covers what new state PEs are expected to retain as part of
supporting IGMP/MLD proxying.  Maybe the answer is "no", but I would
like to have the conversation.

(2) I am not sure if the body text is consistent with what is being
allocated from IANA.  §8 describes PEs that are not using ingress
replication as being identifiable as """any PE that has advertised an
Inclusive Multicast Tag route for the BD without the "IGMP Proxy
Support" flag""", but the IANA considerations allocate flags for both
IGMP Proxy Support and MLD Proxy Support.  Is a PE that advertises MLD
Proxy Support but not IGMP Proxy Support to be treated as not using
ingress replication, as the literal interpretation of this text would
require?  Similarly, §9.2.1 and §9.3.1 include restrictions on
indication of support for "IGMP Proxy" with no mention of "MLD Proxy".
I do see that there is a generic disclaimer at the end of Section 3 but
the way it is written does not actually seem to cover this usage.


--
COMMENT:
--

As one of the directorate reviewers noted (and Éric promoted to a
DISCUSS), this document does not really give any specific description of
how an EVPN PE should construct outgoing IGMP/MLD messages to send out
on its ACs as a result of receiving EVP information over BGP.  From a
brief examination of the relevant IGMP messages, it seems that the EVPN
messages might actually contain information to populate literally all
the IGMP fields, but this is probably worth mentioning explicitly.  In
particular, guidance might be interesting for (e.g.) IGMPv3, that lets
multiple Group Records be included in a single Membership Report.
(Pedantically, such IGMPv3 multiplexing might also require phrasing
changes for the reverse process, taking IGMP and constructing EVPN
routes, since we refer to (e.g) "the Group address of the IGMP
Membership Report" in places, and that is not a well-defined concept in
the absence of some text indicating group-by-group processing.)

Abstract

   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.

I see Lars already noted the dangling reference to "above services".
That really needs to be fixed before approval, and even looking at the
diff from -12 to -13 does not give me a clear picture of what to suggest
as a rewrite.

Section 1

I strongly suggest mentioning and referencing some of the core
technologies that readers are assumed to be familiar with (e.g., RFC
7432 for EVPN, RFC 6514 for various tunnel types including Ingress
Replication).  At present the document is quite unfriendly to a reader
from an outside field, who has little to no indication as to what
background material is required in order to be able to make sense of
this document.

   In DC applications, a point of delivery (POD) can consist of a

Data Center is not marked as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and needs to
be expanded on first use.

   2.  Distributed anycast multicast proxy: it is desirable for the EVPN
   network to act as a distributed anycast multicast router with

I honestly don't know what a "distributed anycast multicast router" is
supposed to be.  Google finds only a handful of instances of that
(quoted) phrase, most of which can be traced back to this document.
There is a similar phrase in §4.2 that perhaps clarifies that the
collection of EVPN PEs is intended to function as a distributed
multicast router (that is perhaps in some sense transparent to the CEs).
But how does the "anycast" part come into play?  How is the anycast IP
address assigned, and which protocol messages 

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

[Warren Kumari via Datatracker]

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

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

[Martin Duke]

+ Brian Trammell (the reviewer)

On Tue, Oct 19, 2021 at 9:06 AM Mankamana Mishra (mankamis) <
manka...@cisco.com> wrote:

> Hi Martin,
>
> Thanks for comment, please find inline comment .
>
>
>
> Mankamana
>
>
>
> *From: *Martin Duke via Datatracker 
> *Date: *Monday, October 11, 2021 at 4:15 PM
> *To: *The IESG 
> *Cc: *draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org <
> draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, bess-cha...@ietf.org <
> bess-cha...@ietf.org>, bess@ietf.org ,
> slitkows.i...@gmail.com 
> *Subject: *Martin Duke's No Objection on
> draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT)
>
> Martin Duke 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:
> --
>
> - It does not appear that you have fully addressed the TSVART comments
> (thanks
> Brian Trammell). Specifically, the (S,G) (*,G) definition is still not
> there.
> Mankamana : I looked at mVPN RFC (6513) , PIM RFC (7761) . all of them do
> use these terminology. But I could not find definition in either of them.
> Do we really need to define it ? want to make sure we do not put some
> definition which restricts the meaning of these generic terminology used in
> multicast across different documents.
>
>  Will this be ok to add ?
>
> (*,G) – Any source multicast flow
>
> (S,G) – Multicast flow with source S and group G.
>
> Please advice.
>
>
> - In the abstract, it refers to "the above services" and I have no idea
> what
> that is referring to.
>
> Mankamana : Will change it to multicast service
>
>
> - Please expand MLD, NLRI, and DF on first use or in the glossary.
>
> Mankamana : will update
>
>
>
> (4.1.1) 1.  When the first hop PE receives several IGMP Membership Reports
>(Joins), belonging to the same IGMP version, from different
>attached hosts for the same (*,G) or (S,G), it SHOULD send a
>single BGP message corresponding to the very first IGMP
>Membership Request (BGP update as soon as possible) for that
>(*,G) or (S,G).
>
> This is confusingly phrased, enough that I think it threw off the TSVART
> reviewer. There is no delay waiting for multiple joins; the PE just sends
> BGP
> for the first and ignores the rest. Or perhaps I've misunderstood? Please
> rephrase.
>
> Mankamana: Membership request are going to be received by IGMP (host
> protocol). If there are multiple ports locally, we may receive joins in
> each of the port. But BGP update is going to be done once. And it should be
> done ASAP .  please let me know if this is still not clear.
>
>
>
> - Relatedly, if a PE receives (S, G) and later (*, G), should it withdraw
> the
> (S, G), since the latter join is a superset of the former?
>
> Mankamana: IGMP V3 RFC defines the group state in case of different joins
> being received on port. This draft does not change the base behavior.
> Rather let IGMP host protocol change the group state based on different
> joins.
>
>
>
> (9) It appears most of the fields in 9.1 through 9.3 are identical; it
> would
> shorten things dramatically if you either had a common section defining
> them or
> simply referred to Sec 9.1. Moreover, as this appears to be cut-and-paste,
> there are mistakes like 9.3 referring to "joins" when it's talking about
> leaves.
> These section
>
> Mankamana- Though content of these section are looking like identical, but
> they talk about different routes.
>
>- Selective multicast (routes needs to be processed by each supporting
>PE participating in same EVPN instance)
>- Multicast join sync (limited to multi-home peer only)
>- Multicast leave sync (limited to multi-home peer only)
>
> Making one common section would lead to too much of confusion for
> implementation.
>
> Thanks for catching typo, will change the join to leave.
>
>
> (9) as you observe that the Source Length can be zero-length for (*,G)
> routes,
> it would be useful to say that the group length can also be zero for (*,*)
> joins. (it might also to constrain it so that if the group length is zero,
> the
> source length MUST also be zero, unless (S, *
>
> *) joins are possible). Mankamana *– For IGMP driven join we would never
> have (*,*) join. But only for selective multicast we can have (*,*). I
> would update the selective multicast section.
>
___
BESS 

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

[Eric Vyncke (evyncke)]

Zhaohui

Thank you for your reply, I am OK with your answers.

Regards

-éric

On 19/10/2021, 20:56, "Jeffrey (Zhaohui) Zhang"  wrote:

Hi Eric,

Thanks for your comments. Please see zzh> below.

-Original Message-
From: Éric Vyncke via Datatracker 
Sent: Monday, October 18, 2021 7:34 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; 
bess-cha...@ietf.org; bess@ietf.org; ext-zzhang_i...@hotmail.com 
; ext-zzhang_i...@hotmail.com 
Subject: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[External Email. Be cautious of content]


É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://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!QSe_FVZLy9LiJjxKR9913uZakS6q0nf4lprT6--xZZ7CwkXwfslLa8KJOu_WRx2D$
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-bum-procedure-updates/__;!!NEt6yMaO-gk!QSe_FVZLy9LiJjxKR9913uZakS6q0nf4lprT6--xZZ7CwkXwfslLa8KJOljIAkWT$



--
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.

Zzh> Yes they're applicable to the 'route type' field. I will change the 
following text:

   "So far eight types have been defined in [RFC7432] ..."

Zzh> to the following (adding "route"):

   "So far eight route types have been defined in [RFC7432] ..."

-- 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 ?

Zzh> RFC 7117 is for VPLS, though we're borrowing some of its text for EVPN 
BUM (with changes pointed out when applied to EVPN) instead of repeating the 
text. Because of that, this does not update RFC 7117 (because we're not 
changing the procedures for VPLS).

Zzh> Thanks!
Zzh> Jeffrey


Juniper Business Use Only

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

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

[Zaheduzzaman Sarker via Datatracker]

Zaheduzzaman Sarker 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:
--

Thanks for working on this document. Thanks to Gorry Fairhurst for his TSVART
review and to the authors for addressing the review comments.

Here, I strongly support Lars's discuss as I also have hard time understanding
the relation towards the updates to RFC 7432 and to RFC 7117 and RFC 7524. The
explanation given in the section 2 is not good enough.

Most of my confusions arose from the way updates/changes/clarifications done to
RFC 7117 and RFC 7524 without describing their relation to RFC 7432 in this
document. Hence to resolve this my suggestion will be to -

* list the updates made to RFC 7432
* describe the relation among RFC 7432, RFC7117, RFC 7524 in the respective
sections where the changes/updates/clarifications are done. Section 5.2 is a
good example for this.

I hope this helps.



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

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[Jeffrey (Zhaohui) Zhang]

Hi Roman,

Thanks for your review and comments. Please see zzh> below.

-Original Message-
From: Roman Danyliw via Datatracker 
Sent: Tuesday, October 19, 2021 7:07 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; ext-zzhang_i...@hotmail.com ; 
ext-zzhang_i...@hotmail.com 
Subject: Roman Danyliw's No Objection on 
draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[External Email. Be cautious of content]


Roman Danyliw 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://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!W9aXZSC6YB_tGS-I05oE_xAchhv7ZbAc7eyvp9QLkay63a9oKtRPkl9f-wuQRPzJ$
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-bum-procedure-updates/__;!!NEt6yMaO-gk!W9aXZSC6YB_tGS-I05oE_xAchhv7ZbAc7eyvp9QLkay63a9oKtRPkl9f-5KAvuRS$



--
COMMENT:
--

** I support Lars Eggert’s DISCUSS position.  I have come to the same
conclusion as the GENART reviewer (Paul Kyzivat).  It isn’t clear what this
document is updating.

-- The document header and abstract explicitly say that RC7432 is updated.
However, I can’t find a clear explanation of how the next in this documents
updates RFC7432

-- Section 5.1. is titled as “Changes to Section 7.2.2 of [RFC7117]” and
changes behavior in RFC7117, but RFC7117 is not being updated (according to the
header and abstract).

Zzh> This document updates RFC7432 in that it provides extensions to support: 
a) selective tunnels b) tunnel segmentation. Perhaps it's arguable that counts 
as "updates". I am fine with removing the "update" tag if that does not count 
as "updates".
Zzh> This document does NOT update RFC7117/7524, which are for VPLS. This 
document is for EVPN (though both are different solutions for ethernet VPNs), 
but it refers to the selective or segmented tunnel procedures for VPLS defined 
in 7117/7524. While minor changes/modifications are needed to apply to EVPN 
(and they are pointed out in this document as you noted), the procedures for 
VPLS are not modified (therefore this document does not update 7117/7524).

Zzh> It was an intentional choice not to copy text from 7117/7524. I understand 
that is causing some concern here but I hope we'd eventually agree that it is 
better than copying text.

** Section 9.
   They do not introduce new security concerns besides what have been
   discussed in [RFC6514], [RFC7117], [RFC7432] and [RFC7524].

Which parts of these security considerations specifically apply here.  For
example, RFC7524 and RFC7432 makes references to MPLS mechanisms (which seem
out of scope here).  Additionally, it appears some of the guidance across these
documents is directed at securing generic EVPN technology – this is helpful,
but please be clear about this case.  What specific guidance is relevant to the
procedures for handling BUM traffic?

Zzh> No guidance. It simply says that there are no new issues/concerns 
introduced by this document, so whatever discussed in those referenced RFCs 
applies here as well.
Zzh> Thanks!
Zzh> Jeffrey



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-pbb-evpn-isid-cmacflush-02

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

I Support this draft, important concept.

Regards
Hooman

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, June 1, 2021 8:48 AM
To: bess@ietf.org
Cc: draft-ietf-bess-pbb-evpn-isid-cmacfl...@ietf.org; bess-cha...@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-pbb-evpn-isid-cmacflush-02

This email starts a two-week working group last call for 
draft-ietf-bess-pbb-evpn-isid-cmacflush-02  [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th June 2021.

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. The document won't progress without answers from all the 
authors and contributors.
There are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] draft-ietf-bess-pbb-evpn-isid-cmacflush-02 - PBB-EVPN ISID-based 
CMAC-Flush
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



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

[bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-13: 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-igmp-mld-proxy/



--
DISCUSS:
--

Thank you for the work put into this document. I have to state that I am
neither a EVPN expert not a multicast one.

Please find below some blocking DISCUSS points (probably easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Stéphane Litkowski for his shepherd's write-up about the WG
consensus.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

The text covers in details how to map MLD/IGMP into BGP routes but does not say
a word on how to recreate the MLD/IGMP packets. Should there be any such
specification ?

Are all multicast group address treated as the same ? I would have appreciated
some text about link-local multicast as well as global multicast groups
addresses.

-- Abstract --
While this point is pretty light for a blocking DISCUSS, let's fix it:
- the abstract should also mention MLD and not only IGMP
- what are 'the above services' ?

-- Section 1 --
In the same vein, is it about IGMP only ? Or does it include MLD as well ? It
is really unclear.


--
COMMENT:
--

A very generic comment (but no need to reply): how can an IETF draft still
prefers to use "IGMP" rather than "MLD" in the text in 2021 ? ...

-- Section 1 --
When reading this section, I really and genuinely wonder what is "distributed
anycast multicast router" ? AFAIK "any cast" and "multicast" addresses are
vastly different.

-- Section 3 --
Is there any reason why the terminology is not alphabetically sorted ?

Please also add 'BD'.

Usually a terminology section is not only about acronym expansions but also
about definitions.

-- Section 4.1 --
What is the definition of a 'first hop PE'? What is the difference with a EVPN
PE ?

-- Section 4.2 --
May be that I overlooked it, but what is a 'proxy querier' ?

What is the difference between "EVPN core" and "MPLS/IP core" ?

-- Section 5.1 --
What is "viz" ? (Sorry not being a native English speaker)

-- Section 8 --
Is there a difference between (*, G) and (x, G) ?

-- Section 9.1 --
Please formally specify "IE" as "include/exclude" (if not mistaken).

I find the description of the bits for MLD confusing, it really appears as a
last-minute add-on to the text. Why not describing the MLDv1 in the same bullet
as in IGMPv1 for the bit 7 ?

Is "SHOULD" the right word for the sender of the reserved bits ? Especially as
section 9.1.1. specifies a "MUST".

-- Sections 9.1, 9.2 --
The flags description appears to be different in the text while it seems to me
that they have the same semantics.

== NITS ==

Is it "ToR" or "TOR" ?

-- Section 4.1.2 --
Please use a consistent quoting in the document, e.g. in :
IGMPv2 Leave Group (Leave) or IGMPv3 "Leave"



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

Re: [bess] [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-optimized-ir-09

[Eric Vyncke (evyncke)]

Thank you Pascal

I have entered a NO OBJECTION ballot on this document with a request to the 
authors (in copy) to reply to all points of your review.

Regards


-éric


On 15/10/2021, 15:44, "Int-dir on behalf of Pascal Thubert via Datatracker" 
 wrote:

Reviewer: Pascal Thubert
Review result: Ready with Issues


https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/reviewrequest/15116/

Intdir Review draft-ietf-bess-evpn-optimized-ir-09

I am an assigned INT directorate reviewer for
draft-ietf-bess-evpn-optimized-ir-09.  These comments were written primarily
for the benefit of the Internet Area Directors.  Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received.  For more details on the INT
Directorate, see https://datatracker.ietf.org/group/intdir/about/.

I find the document to be well written but would benefit for clarification 
of
what IR is (pro/con vs multicast tree, which node does what) at the very
beginning. Overall I think the draft is ready with nits for publication.

High level: I'm curious about link scope IPv6 multicast packets. I 
understand
that MLDv2 is forwarded following regular IR procedures. Isn't that the case
for all link scope IPv6 multicast (FF02::/16) ?

 [Page 2] The introduction uses IR as if the reader new what it is before 
hand.
 Maybe a bit more explanantion could help. Also, a simple fig illustrating 
NVE
 PE etc would help figure what is and does what, in particular what to 
expect
 from an IR function.

 Page 5 : define PMSI, e.g., copy the terminology from
 draft-ietf-bess-evpn-bum-procedure-updates

 Page 3 : "The Inclusive Multicast Ethernet Tag route (RT-3) and its PMSI
 Tunnel Attribute’s (PTA) general format used in [RFC7432] are shown below:"

Unclear whether the below is the original format in RFC 7432 or the 
variation
instantiated for this document, which flags are already defined and which 
are
added by this spec.

For flags added for this spec to an existing field, it would make sense to 
add
that the flag positions are "suggested to IANA"?

Also, a figref would be nice as opposed to "below:"

"This document defines the use of 4 bits of this Flags field:"
It would be helpful to confirm the intuition that the bits are counted 0 to 
7
left to right.

"MUST be set to an IP address of the PE that should be": strange construct.
The effect of the "MUST" appears destroyed by the "should".

"  The Tunnel Identifier and
Next-Hop SHOULD be set to the same IP address as the
Originating Router’s IP address when the NVE/PE originates the
route. The Next-Hop address is referred to as the AR-IP and
SHOULD be different than the IR-IP for a given PE/NVE."
What are the consequences of not obeying those SHOULD?
Please explain there when/why the node uses both IR-IP and AR-IP. Some text 
here
would prepare for the reasons which can be inferred from behavior in page 
11/12
but are not explicitly given.

Fig 1: please indicate the ACs

Page 11: " An AR-REPLICATOR will follow a data path implementation 
compatible
   with the following rules:" Should that be a MUST?

Page 13:"In case of a failure on the selected AR-REPLICATOR, another
  AR-REPLICATOR will be selected" is that a SHOULD or a "MUST if
  available"?

Page 13: "When an AR-REPLICATOR is selected, the AR-LEAF MUST send all
  the BM packets to that AR-REPLICATOR " contradicts
  "An AR-LEAF MAY select more than one AR-REPLICATOR and do
  either per-flow or per-BD load balancing."
  I guess it should say that the multicast packets are load-balanced
  across of the selected ARs using unicast underlay encapsulation.

Section 6:

Maybe indicate what the selective method does (build 2 hops trees) and the
consequence (failure if an AR prevents the AR Leaves attached to it to send 
and
receive multicast traffic till it's attached to a new AR.

Page 15  "Figure 1 is also used to describe the selective AR solution, 
however
   in this section we consider NVE2 as one more AR-LEAF for BD-1. ":
   please make that a new figure 2

page 17: "A Selective AR-REPLICATOR data path implementation will be 
compatible
   with the following rules: " MUST again? reword maybe?



___
Int-dir mailing list
int-...@ietf.org
https://www.ietf.org/mailman/listinfo/int-dir

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