[bess] Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-mh-split-horizon-10: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Jorge,

Thanks for your reply, the fix, and the explanations. All is good for me and I 
think the I-D is in better shape.

Regards

-éric

From: Jorge Rabadan (Nokia) 
Date: Sunday, 18 August 2024 at 03:17
To: Eric Vyncke (evyncke) , The IESG 
Cc: draft-ietf-bess-evpn-mh-split-hori...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 
, Mankamana Mishra (mankamis) , 
zzh...@juniper.net , Matthew Bocci (Nokia) 

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-mh-split-horizon-10: (with COMMENT)
Hi Éric,

We appreciate your thorough review. Your comments are addressed in version 11.
Please see in-line with [jorge].

Thank you!
Jorge

From: Éric Vyncke via Datatracker 
Date: Tuesday, August 6, 2024 at 7:33 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-mh-split-hori...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 
, manka...@cisco.com , 
zzh...@juniper.net , Matthew Bocci (Nokia) 
, zzh...@juniper.net 
Subject: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-mh-split-horizon-10: (with COMMENT)

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.



Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-mh-split-horizon-10: 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C9e59d462f46b45ea465b08dcb624c8bf%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638585516324369241%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FnzSx%2FEKV0ehv65IwKvOTSh294V2jjf%2F79UvADaej0c%3D&reserved=0<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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-evpn-mh-split-horizon%2F&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C9e59d462f46b45ea465b08dcb624c8bf%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638585516324380377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vyM4nECn5SeYwMdGq2rtOawV6oFIehNo2uUWPoToOu8%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/>



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-mh-split-horizon-10

Thank you for the work put into this document. I found the writing quite
convoluted and not easy to follow, especially about what is modified from RFC
7432 and others.

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

Special thanks to Jeff Zhang for the shepherd's write-up including the WG
consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Relevance to BESS ?

Wondering whether this work fits well within BESS charter; some EVPN (e.g.,
VXLAN) are deployed without using BGP and still require split-horizon (if not
mistaken).

Strongly suggest to add BGP in the title of this document (and abstract) to
make it clear that this is about BGP and not EVPN.
[jorge] As defined in RFC7432, EVPN is always BGP-based, i.e. it requires the 
exchange of BGP NLRIs to implement all the procedures in the RFC. We added BGP 
in the title.


## Abstract

`to select the appropriate Split Horizon procedure` does it mean that the other
procedure is *not* appropriate or simply *less* appropriate ?
[jorge] not really, it means that the other procedure may be appropriate too, 
but the operator prefers one over the other for any reason that is out of 
scope. For example, an operator may prefer “local bias” because always forwards 
the traffic locally to other multihomed attachment circuits irrespective of who 
the designated forwarder is, as opposed to send it to the peer PE. I changed 
the text to the following, hopefully it improves the readability:
“to select the Split Horizon procedure that meets their specific requirements”


## Section 1

Suggest to clearly define "split horizon" rather than simply burry it in `Split
Horizon procedures employed to prevent looped frames`.
[jorge] We added the following, hopefully it helps:
“Split Horizon, in thi

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)

[Eric Vyncke (evyncke)]

Thank you, Jorge, for your email.

I still have doubts about the scalability effect of MAC addresses either 
changing or moving. The MAC address landscape has changed since RFC 7623 ;-) 
But, this is a non-blocking comment.

Regards

-éric

From: Jorge Rabadan (Nokia) 
Date: Monday, 23 October 2023 at 13:21
To: Eric Vyncke (evyncke) , The IESG 
Cc: draft-ietf-bess-pbb-evpn-isid-cmacfl...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci (Nokia) 

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)
Hi Éric,

Thanks very much for your review.

Please see in-line with [Jorge].

Thanks!
Jorge

From: Éric Vyncke via Datatracker 
Date: Monday, August 7, 2023 at 10:21 PM
To: The IESG 
Cc: draft-ietf-bess-pbb-evpn-isid-cmacfl...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci (Nokia) 
, Matthew Bocci (Nokia) 
Subject: Éric Vyncke’s No Objection on 
draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)

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.



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


# Éric Vyncke, INT AD, comments for draft-ietf-bess-pbb-evpn-isid-cmacflush-08

Thank you for the work put into this document. This is a very specific area of
work and the text is not easy to read for a non expert. So, I was happy to rely
on the Internet directorate review below by Pascal.

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

Special thanks to Matthew Bocci for the shepherd’s detailed write-up including
the WG consensus and the justification of the Intended status.

Other thanks to Pascal Thubert, the Internet directorate reviewer (at my
request), please consider this int-dir review as if it was mine:
https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/reviewrequest/17846/
[Jorge] yup, comments are addressed in version 9. Thanks Pascal!


I hope that this review helps to improve the document,
[Jorge] absolutely, thanks.


Regards,

-éric

# COMMENTS

## Abstract

No need for action, but I have rarely seen such an acronym-dense abstract, it
is therefore hard to read.
[Jorge] hopefully it is now slightly easier to read.


## G.8032

G.8032 should be an informative reference (this would be DISCUSS level issue if
the reference was normative).
[Jorge] added as informative reference


## Scalability

Should there be some text about the scalability issues ? I.e., MAC addresses
move (Wi-Fi roaming) and are changing (cfr MADINAS WG).
[Jorge] the document does not have any changes with respect of the handling of 
customer MACs, other than what is described in RFC7623, hence the security 
considerations refer to the ones in RFC7623. As for the service provider 
B-MACs, the security considerations section describes the consumption of 
additional memory in the PEs due to the new mechanisms. Hopefully that is 
enough.




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

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

[Eric Vyncke (evyncke)]

Thank you, Jorge, for taking the time to reply.

I can only regret the use of “DP” rather than “DNP”, but you have a point if 
there are existing implementations.

Regards

-éric

From: Jorge Rabadan (Nokia) 
Date: Friday, 6 October 2023 at 21:51
To: Eric Vyncke (evyncke) , The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 

Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: 
(with COMMENT)
Hi Éric,

Thanks very much for the review. Your comments are addressed in version 12.

Please see in line with [Jorge] for more details.

Thanks.
Jorge

From: Éric Vyncke via Datatracker 
Date: Tuesday, August 1, 2023 at 2:35 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: (with 
COMMENT)

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.



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



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-pref-df-11

Thank you for the work put into this document. Please note that I was close to
ballot a DISCUSS based on my non-blocking COMMENT points, but as I am not an
expert in EPVN, I am trusting the responsible AD.

Please find below osome non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and several nits (please run
your I-D through a spell-checker).
[Jorge] all the nits are fixed now, thanks


Special thanks to Stéphane Litkowski for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status even if
using the old template.

I hope that this review helps to improve the document,
[Jorge] it does, thank you very much.


Regards,

-éric

# COMMENTS

## Abstract

Please fix the expansion of BUM as it is not `Broadcast, Unknown unicast and
Broadcast traffic (BUM)` ;-)
[Jorge] fixed, thanks


## Section 1.1

Please fix the expansion of BUM as it is not `Broadcast, Multicast and Unknown
unicast traffic (BUM)` ;-) I was amused to read two different wrong expansions
for BUM ;-)
[Jorge] yeah, we should have caught it way earlier ☹ - It’s fixed now, thanks


I am sure that non SP will also use this technique, i.e., I wonder whether
s/Service Providers/Network Operators/ would be beneficial.
[Jorge] good point, changed now.


## Section 2

Rather than using "DP" in `DP - refers to the "Don't Preempt me"` should "DNP"
be more logical ?
[Jorge] maybe, but at this point with so many implementations (and debug 
commands showing DP), I prefer to keep it as DP. Hopefully it is ok.


## Section 3

Should RFC 8584 be formally updated as its reserved field is carved out ?

`The DP capability is supported by DF Algorithms Highest-Preference or
Lowest-Preference, and MAY be used with the default DF Algorithm or HRW
[RFC8584]` Is there any migration concern with the use of MAY ? I.e., part of
the participating routers will use the DP and the other part not => leading to
an inconsistent election result.
[Jorge] the reason why we added this was to leave the door open to use the DP 
capability with other DF Algorithms, but you are right that the above text is 
confusing, especially because the intent was not to specify how to use it for 
the default and HRW algorithms, but to say that the use of DP for any other 
algorithm is out of scope. So we changed the text to:
 The DP capability is supported
 by the Highest-Preference or Lowest-Preference DF Algorithms.
 The procedures of the "Don't Preempt" capability for other DF
 Algorithms are out of the scope of this document.



# NITS

s/tie-breakers/tiebreakers/
s/The existence of both provide/The existence of both provides/
s/achive/achieve/ ?
s/decribed/described/

'e.g.' is usually surrounded by ','
[Jorge] all fixed now





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

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Jeffrey,

Thanks again for your reply. Please look below for EV>

-éric

From: Jeffrey (Zhaohui) Zhang 
Date: Wednesday, 4 October 2023 at 20:24
To: Eric Vyncke (evyncke) , The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)
Hi Eric,

Thanks for your additional comments.
Please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Éric Vyncke via Datatracker 
Sent: Wednesday, October 4, 2023 4:54 AM
To: The IESG 
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; slitkows.i...@gmail.com; slitkows.i...@gmail.com
Subject: Éric Vyncke's No Objection on 
draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)

[External Email. Be cautious of content]


Éric Vyncke 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!FEgMbJglM32kNpUq8oHsJACNotxG8OsVTbawC8CSmY6LxXGvbXL5dg2IGipM1_A9Gt7HJwasAU7uYvU$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!FEgMbJglM32kNpUq8oHsJACNotxG8OsVTbawC8CSmY6LxXGvbXL5dg2IGipM1_A9Gt7HJwasAU7uYvU$>
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-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!FEgMbJglM32kNpUq8oHsJACNotxG8OsVTbawC8CSmY6LxXGvbXL5dg2IGipM1_A9Gt7HJwasNmJJFr4$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!FEgMbJglM32kNpUq8oHsJACNotxG8OsVTbawC8CSmY6LxXGvbXL5dg2IGipM1_A9Gt7HJwasNmJJFr4$>



--
COMMENT:
--

Thanks to Zhaohui Zhang and Stéphane Litkowski for addressing my previous 
DISCUSS points (even if they were 'discuss discuss', i.e., just to have a 
discussion). I have now cleared my previous DISCUSS ballot.

# COMMENTS

## Abstract

Should the abstract qualify the VPN with layer-3 (for MVPN) and layer-2 (for
EVPN) ?

Zzh> In this document, VPN refers to IP VPN. L2 VPN is specifically EVPN.
Zzh> I can change VPN to IP VPN in the abstract, and then in the first section 
clarify that VPN specifically refers to IP VPN.
Zzh> Is that ok?

EV> perfect

## Section 1

Should "SR" also be expanded ? Should RFC 8660 be a reference ?

Zzh> Changed and added.

## Section 2

`to transmit multicast traffic or BUM traffic` is somehow redundant as BUM 
includes multicast.

Zzh> Changed to "to transmit VPN multicast  traffic or EVPN BUM traffic".

## Section 2.1

`At the present time` what about "In 2023, " ?

Zzh> Changed to "So far, ".

EV> still “so far” does not age well ;-)


## Section 3.1

Please expand "EC" at first use (even if it can be guessed on the previous 
sentence).

Zzh> Fixed.

Why this section use `to be defined by IANA`, while section 5 lists the 
IANA-assigned values ?

Zzh> Fixed.

## Section 3.2

This I-D uses 'outside the scope of this document' twice. I am curious: is 
there any work in BESS WG for this ?

Zzh> No at this time 😊
Zzh> Coordinated label assignment is like IP address assignment.
Zzh> Ensuring all PEs supporting the procedures is like an operator making sure 
that all its PEs are running a certain software release.

# NITS

zzh> All fixed. To be posted.
Zzh> Thanks!
Zzh> Jeffrey

## Section 1

s/Terminologies/Terminology/

s/Broadcast, Unknown *U*nicast, or Multicast (traffic)/Broadcast, Unknown 
*u*nicast, or Multicast (packet)/

s/sub set/subset/


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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-11: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Thank you, let's wait until the shepherd updates his write-up, then I am 
clearing my DISCUSS

-éric

On 29/09/2023, 16:38, "Jeffrey (Zhaohui) Zhang" mailto:zzh...@juniper.net>> wrote:


Hi Eric,


Thanks for your thorough review.
I have submitted the -12 revision that fixes the reference error (and addresses 
comments from Erik Kline).


Jeffrey




Juniper Business Use Only
-Original Message-
From: Éric Vyncke via Datatracker mailto:nore...@ietf.org>>
Sent: Friday, September 29, 2023 6:30 AM
To: The IESG mailto:i...@ietf.org>>
Cc: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org 
; 
bess-cha...@ietf.org ; bess@ietf.org 
; slitkows.i...@gmail.com 
; slitkows.i...@gmail.com 

Subject: Éric Vyncke's Discuss on 
draft-ietf-bess-mvpn-evpn-aggregation-label-11: (with DISCUSS and COMMENT)


[External Email. Be cautious of content]




Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DjXuL1noCSa5WhUuS_bagMtl618K7y88Y_-qasDkUDNDfZ35V5l7ZaLNrjHA44aocSkdXbcTESUiVoY$
 

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-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!DjXuL1noCSa5WhUuS_bagMtl618K7y88Y_-qasDkUDNDfZ35V5l7ZaLNrjHA44aocSkdXbcT1sqDXoM$
 







--
DISCUSS:
--


# Éric Vyncke, INT AD, comments for
draft-ietf-bess-mvpn-evpn-aggregation-label-11


Thank you for the work put into this document.


Please find below two blocking DISCUSS points (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 the shepherd's detailed write-up 
including the WG consensus ***but it lacks*** the justification of the intended 
status.


I hope that this review helps to improve the document,


Regards,


-éric


# DISCUSS


As noted in 
https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!DjXuL1noCSa5WhUuS_bagMtl618K7y88Y_-qasDkUDNDfZ35V5l7ZaLNrjHA44aocSkdXbcTXkvFe6c$
 

 , a DISCUSS ballot is a request to have a discussion on the following topics:


## Shepherd write-up


The shepherd write-up includes `Martin Vigoureux is the responsible AD`.


The shepherd write-up includes `There is one IPR`, while data tracker has 2 IPR 
declarations. At least, the auto-generated IETF Last Call correctly listed the 
two IPR declarations.


The above parts are obviously outdated and MUST be updated.


This is not really a DISCUSS criteria, so I will change my ballot after the 
IESG formal telechat or after an update of the shepherd write-up (the earlier).


## Wrong reference to RFC5531


As indicated by idnits, there is a reference to RFC 5531 (it should probably be 
RFC 5331)




--
COMMENT:
--




# COMMENTS


## Abstract


Should the abstract qualify the VPN with layer-3 (for MVPN) and layer-2 (for
EVPN) ?


## Section 1


Should "SR" also be expanded ? Should RFC 8660 be a reference ?


## Section 2


`to transmit multicast traffic or BUM traffic` is somehow redundant as BUM 
includes multicast.


## Section 2.1


`At the present time` what about "In 2023, " ?


## Section 3.1


Please expand "EC" at first use (even if it can be guessed on the previous 
sentence).


Why this section use `to be defined by IANA`, while section 5 lists the 
IANA-assigned values ?


## Section 3.2


This I-D uses 'outside the scope of this document' twice. I am curious: is 
there any work in BESS WG for this ?

[bess] Errata 7180 on RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)

[Eric Vyncke (evyncke)]

As the L3VPN activities have been transferred to the BESS WG, I would 
appreciate feedback from the BESS WG on this errata.
https://www.rfc-editor.org/errata_search.php?eid=7180

The section 4.3.4 text
"   Note that this VPN architecture does not require the capability to
   distribute unlabeled VPN-IPv4 addresses."

Is suggested to be replaced by
"  Note that this VPN architecture does not require the capability to
   distribute unlabeled IPv4 addresses.

With the errata reporter note: From my understanding, VPN-IPv4 addresses are 
necessarily labeled, but IPv4 adresses are not indeed. Section 10 seems to 
confirm the error by using the correct term: "distribute unlabeled IPv4 
addresses to each other."

Thanks in advance for your review,

-éric


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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Thank you, Parag, for the changes.

As you have seen by now, I have cleared my previous DISCUSS ballot.

Regards

-éric

PS: please accept my apologies for delayed reaction

From: "Parag Jain (paragj)" 
Date: Monday, 8 May 2023 at 19:22
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-lsp-p...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , Matthew Bocci 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with 
DISCUSS and COMMENT)

Hello Eric

Thank you for your careful review and valuable comments. We have addressed them 
in version 10 of the draft.

Pls also see inline.


From: Éric Vyncke via Datatracker 
Date: Monday, April 24, 2023 at 6:02 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, matthew.bo...@nokia.com 
Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with 
DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-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/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/



--
DISCUSS:
--

Thank you for the work put into this document, it can only help operations.

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

Special thanks to Matthew Bocci for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Missing normative references

Even experienced authors sometimes forget to add normative references to RFC
2119 and RFC 8174 ;-)
Paragj> added reference to rfc2119 and rfc8174.

## Section 4.4

Probably due to my lack of knowledge about EVPN and RFC 9136 et al, but I
wonder how the length of the "IP Prefix" field can be known by the receiver ?
There is a "IP Prefix length" field but it seems to indicate the prefix length,
e.g., "IP Prefix Len" field could be 32 bit but the "IP Prefix" field itself
could be the 128-bit value of 2001:db8::

May I strongly suggest adding clarification text if my understanding is
incorrect ?
Paragj>Added clarification text as follows:
The EVPN IP Prefix Sub-TLV has the format as shown in Figure 4. The total 
length of this sub-TLV can be either 32 if IPv4  addresses are carried or 56 if 
IPv6 addresses are carried.  The IP prefix and gateway IP address must be from 
the same IP address family.


--
COMMENT:
--


# COMMENTS (non blocking)

## Typos

I had not the same patience as Jim Guichard for catching all typos... But, it
is surprising that there are so many left at this stage of the publication
process. Please run a proof reader.

Paragj> fixed.

## Section 1

Please expand "PBB" at first use.
Paragj> done


## Section 4.1

Even if the old RFC 7432 (dated 8 years ago) only understands 48-bit MAC
addresses, there are MAC addresses with different length. Should this document
handle those MAC addresses ?
Paragj> updated the doc to state that only 48 bit mac addresses are supported.

## Section 6.1

Is there a reason why the MAC addresses are not written in the IEEE standard
way ? I.e., "00aa.00bb.00cc" should be written as "00-AA-00-BB-00-CC".
Paragj> done

In 2023, I would have preferred to have an IPv6 example rather than an IPv4 one.
Paragj>Fixed.

## Section 7

Are there mitigation techniques ?

paragj> added text.
Thanks
Parag
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Eric Vyncke (evyncke)]

I like this wording Luc André as it is less clumsy than existing text.

Anyway, the -19 addresses my only remaining blocking DISCUSS point, so, I am 
clearing my DISCUSS in the following minutes.

I hope that all this discussion has improved the document.

Respectfully yours,

-éric



From: Luc André Burdet 
Date: Saturday, 5 March 2022 at 16:06
To: "Mankamana Mishra (mankamis)" , Eric 
Vyncke , John E Drake , 
The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "slitkows.i...@gmail.com" , 
"bess@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi Éric, Mankamana & John,

Just read -19 viz this thread.
The IGMP/MLD duality has been seen before and in previous cases (RFC4604) it 
was explicitly called out also  (for good cause: IGMP Membership vs MLD 
Listener,  IGMP Leave vs MLD Done, etc)



RFC3376:

   In this document, unless otherwise qualified, the capitalized words

   "Query" and "Report" refer to IGMP Membership Queries and IGMP

   Version 3 Membership Reports, respectively.



RFC3810:

   In this document, unless otherwise qualified, the capitalized words

   "Query" and "Report" refer to MLD Multicast Listener Queries and MLD

   Version 2 Multicast Listener Reports, respectively.



RFC4604:

   Due to the commonality of function, the term "Group Management

   Protocol", or "GMP", will be used to refer to both IGMP and MLD.  The

   term "Source Filtering GMP", or "SFGMP", will be used to refer

   jointly to the IGMPv3 and MLDv2 group management protocols.




Could I propose just adding a small clarifying paragraph in Intro which does 
the same as those 3 and use that terminology?



The term "Group Management Protocol", or "GMP", was first defined in RFC4604 to 
address the commonality of function between IGMP and LMD.

In this document, unless otherwise qualified:

-the capitalized words "GMP Query" refer to IGMP Membership Queries and MLD 
Multicast Listener Queries; and

-the capitalized words "GMP Report" refer to IGMP Version X Membership 
Reports and MLD Version 2 Multicast Listener Reports.

s/ IGMP Membership Reports/GMP Reports/g


Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: BESS  on behalf of Mankamana Mishra (mankamis) 

Date: Friday, March 4, 2022 at 12:09
To: Eric Vyncke (evyncke) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, slitkows.i...@gmail.com , 
bess@ietf.org 
Subject: Re: [bess] Éric Vyncke's Discuss on 
draft-ietf-bess-evpn-igmp-mld-proxy-18: (with DISCUSS and COMMENT)
Hi Eric,
Posted new revision addressing two of your comment

1.   Latest comment about adding IGMP / MLD before terminology

2.   Pending from last one, where section 4.1.1 numbers were getting reset 
without comment


Mankamana

From: Mankamana Mishra (mankamis) 
Date: Friday, March 4, 2022 at 7:42 AM
To: Eric Vyncke (evyncke) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Thanks, positing update in 30 min.

Mankamana

From: Eric Vyncke (evyncke) 
Date: Friday, March 4, 2022 at 7:36 AM
To: Mankamana Mishra (mankamis) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Correct this will address my DISCUSS point if you also modify the line below, 
i.e., replace all IGMP by IGMP/MLD in the text until the terminology section 
states "IGMP means IGMP or MLD" (sic).

Regards

-éric


From: "Mankamana Mishra (mankamis)" 
Date: Friday, 4 March 2022 at 16:33
To: Eric Vyncke , John E Drake 
, The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi Eric,

These hosts/VMs express their interests in multicast groups on a
   given subnet/VLAN by sending IGMP Membership Reports (Joins) for. >> Adding 
MLD here too ?
   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 has three obj

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

[Eric Vyncke (evyncke)]

Correct this will address my DISCUSS point if you also modify the line below, 
i.e., replace all IGMP by IGMP/MLD in the text until the terminology section 
states "IGMP means IGMP or MLD" (sic).

Regards

-éric


From: "Mankamana Mishra (mankamis)" 
Date: Friday, 4 March 2022 at 16:33
To: Eric Vyncke , John E Drake 
, The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi Eric,

These hosts/VMs express their interests in multicast groups on a
   given subnet/VLAN by sending IGMP Membership Reports (Joins) for. >> Adding 
MLD here too ?
   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 has three objectives:


does this change look ok ?

From: Eric Vyncke (evyncke) 
Date: Friday, March 4, 2022 at 7:29 AM
To: John E Drake , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Hello John,

Thanks for your quick reply, even if I am unsure how to read " Yours 
Irrespectively," as I am not an English-native person.

Thank you for pointing me to the new sections 9.1.2 & others => I will update 
my DISCUSS on this point w/o sending another email.

But section 1 still mentions only IGMP and never MLD except for "IGMP/MLD" 
proxy, this is trivial to fix, so I suggest to the authors to update the draft.

Regards

-éric

-Original Message-
From: iesg  on behalf of John E Drake 

Date: Friday, 4 March 2022 at 15:01
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi,

Snipped, comments inline

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-

> DISCUSS:
> --
>
> As Martin Vigoureux's term is near its end, I took the liberty to 
re-evaluate the
> ballot status of this document and clearing parts of my original block 
DISCUSS
> points and many of my original non-blocking COMMENT points.
>
> See below this line for updated version
> --
>
> 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 (e.g., in section 4.1) ?

[JD]  We added:

9.1.2.  Reconstructing IGMP / MLD Membership Reports from Selective 
Multicast Route

9.2.2.  Reconstructing IGMP / MLD Membership Reports from Multicast 
Membership Report Sync Route

9.3.2.  Reconstructing IGMP / MLD Leave from Multicast Leave Sync Route

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

[JD]  The Abstract states:   This document describes how to support 
efficiently endpoints running IGMP
(Internet Group Management Protocol) or MLD (Multicast Listener  Discovery) 
for the multicast services
over an EVPN network by incorporating IGMP/MLD proxy procedures on EVPN 
(Ethernet VPN) PEs.

We also added this paragraph to section 3 at Ben's behest:

It is important to note when there is text considering whether a PE 
indicates support for IGMP proxying,
the corresponding behavior has a natural analogue for indication of support 
for MLD proxying, and the
analogous requirements apply as well.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Eric Vyncke (evyncke)]

Hello John,

Thanks for your quick reply, even if I am unsure how to read " Yours 
Irrespectively," as I am not an English-native person.

Thank you for pointing me to the new sections 9.1.2 & others => I will update 
my DISCUSS on this point w/o sending another email.

But section 1 still mentions only IGMP and never MLD except for "IGMP/MLD" 
proxy, this is trivial to fix, so I suggest to the authors to update the draft.

Regards

-éric

-Original Message-
From: iesg  on behalf of John E Drake 

Date: Friday, 4 March 2022 at 15:01
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi,

Snipped, comments inline

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-

> DISCUSS:
> --
> 
> As Martin Vigoureux's term is near its end, I took the liberty to 
re-evaluate the
> ballot status of this document and clearing parts of my original block 
DISCUSS
> points and many of my original non-blocking COMMENT points.
> 
> See below this line for updated version
> --
> 
> 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 (e.g., in section 4.1) ?

[JD]  We added: 

9.1.2.  Reconstructing IGMP / MLD Membership Reports from Selective 
Multicast Route

9.2.2.  Reconstructing IGMP / MLD Membership Reports from Multicast 
Membership Report Sync Route

9.3.2.  Reconstructing IGMP / MLD Leave from Multicast Leave Sync Route

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

[JD]  The Abstract states:   This document describes how to support 
efficiently endpoints running IGMP
(Internet Group Management Protocol) or MLD (Multicast Listener  Discovery) 
for the multicast services
over an EVPN network by incorporating IGMP/MLD proxy procedures on EVPN 
(Ethernet VPN) PEs.

We also added this paragraph to section 3 at Ben's behest:

It is important to note when there is text considering whether a PE 
indicates support for IGMP proxying,
the corresponding behavior has a natural analogue for indication of support 
for MLD proxying, and the
analogous requirements apply as well.

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

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

[Eric Vyncke (evyncke)]

Hello Mankamana,

Thanks for your reply, see below for EV> (I have elided the original DISCUSS 
part). As soon as a revised I-D is uploaded, then I am clearing my DISCUSS.

Regards

-éric


From: "Mankamana Mishra (mankamis)" 
Date: Friday, 11 February 2022 at 00:33
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 
"slitkows.i...@gmail.com" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)

Hi Eric,
Thanks for comment.


  1.  For text which talks about how to decode BGP routes back , will it be ok 
to have common section after BPG encoding 
(https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-9)
 ? which talks about fact that receiving PE need to decode it back and consider 
it as IGMP membership request and process it ?
EV> adding sections 9.1.3 / 9.2.3 / 9.3.3 "reconstructing the MLD/IGMP" per 
route type would be preferred of course, but a common subsection on 
reconstruction either after 9.3 (preferred) or after 9.1 would be OK (in the 
sense that it addresses my DISCUSS but is less easy for the 
readers/implementers)


  1.  About number restarting – There was comment by Alvaro where he wanted 
these numbers to be restarting to differentiate sender and receiver processing
EV> I am sure that Alvaro will not mind have some text, even just 4 words, 
separating the sender / receiver processing


  1.  SMET, I would take care of it in terminology.
EV> thanks


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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-srv6-services-09: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Hello Ketan

Thank you for your prompt reply and for uploading a revised I-D. I am also 
sorry for my belated reply :-(

The revised I-D addresses all my DISCUSS points, i.e., I am clearing my ballot 
into a NO OBJECTION in a couple of hours (I have a call now).

About the non-blocking COMMENT, I still find the examples of section 4 really 
unclear but let's hope that readers, who are more fluent than me about BGP, 
will find them useful.

Best regards

-éric


From: Ketan Talaulikar 
Date: Tuesday, 8 February 2022 at 18:06
To: Eric Vyncke 
Cc: The IESG , "draft-ietf-bess-srv6-servi...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , "Bocci, Matthew (Nokia 
- GB)" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-srv6-services-09: (with 
DISCUSS and COMMENT)

Hi Eric,

Thanks for your review and comments/feedback. Please check inline below for 
responses.

We've also just posted an update to address your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-10


On Tue, Feb 8, 2022 at 3:16 AM Éric Vyncke via Datatracker 
mailto:nore...@ietf.org>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-srv6-services-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-srv6-services/



--
DISCUSS:
--

Thank you for the work put into this document. This protocol is important for
scalable and deployable SRv6 services.

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

Special thanks to Matthew Bocci for the shepherd's write-up including the
section about the WG consensus and document history.

Please also expect an INT directorate review before the IESG telechat (I may
update this ballot accordingly).

I hope that this helps to improve the document,

Regards,

-éric

# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Section 3.1

"IANA registry defined in section 9.2 of [RFC8986]" but there is no section 9.2
in RFC 8986. I guess it is section 10.2. Moreover, IANA registries are usually
referred to via their name/URL, e.g.,
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml, and not
by a section of the RFC that created them.

KT> Ack. It should have been Section 10.2. We have updated the text as below:

Encodes SRv6 Endpoint behavior codepoint value that is associated with SRv6 
SID. The codepoints used are from the SRv6 Endpoint Behavior registry under the 
IANA Segment Routing Parameters registry that was introduced by [RFC8986].


## Section 3.2.1

Where is "locator node" defined ? "locator block" is defined in section 3.1 of
RFC 8986 but not the node (I can only guess that this is the "N" in the "B:N"
notation used in RFC 8986).

KT> Your understanding is correct. We have added the text below

The terms Locator Block and Locator Node correspond to the B and N parts 
respectively of the SRv6 Locator that are defined in section 3.1 of [RFC8986].


## Section 6

Section 9 of draft-ietf-bess-evpn-igmp-mld-proxy-16 indeed defines route types
7 and 8 but it uses non IPv4-only wording. So, s/IGMP join sync route/Multicast
Membership Report Synch Route/ + same for type 8.

KT> Ack. We have fixed to use route type names as per the latest version of 
draft-ietf-bess-evpn-igmp-mld-proxy.



--
COMMENT:
--

# COMMENTS

## Section 1

More details on the encapsulation (plain IP in IPv6 ?) will be welcome in "The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   Provider Edge (PE). "

KT> The inner packet being the service traffic, will vary (IPv4, IPv6, or 
Ethernet) and hence is not described here. We have added text in sections 5 and 
6 to refer to the H.Encaps and H.Encaps.L2 behaviors introduced in RFC8986 to 
explain the encapsulations.


## Section 3.2.1

The transposition field appears to be about "labels", which are not qualified.
Should the reader assume that those are "MPLS labels" ? A reference to some
text would be welcome. Not being a SRv6 expert (but somehow knowledgeable on
the topic), all the text about transposition is completely opaque to 

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

[Eric Vyncke (evyncke)]

Hello Mankamana and other authors,

Is there a plan to solve my remaining blocking DISCUSS point ? I.e., how can a 
recipient EVPN speaker can translate back the BGP information into MLD/IGMP 
packets?

Section 4.1 contains " The information is again translated back to IGMP message 
at the recipient EVPN speaker." But the translation is not specified. This 
should be required in a proposed standard document. I.e., multiple sections are 
about MLD/IGMP messages received by a PE, format of the BGP messages, but never 
how to generate MLD/IGMP from those routes. Even if trivial for the authors, 
some description, even short, is really required.

BTW, in section 4.1.1 of revision -16, I find the numbering of the rules really 
confusing as it restarts from 1. Strongly suggest adding a preamble between 
rule 4 and rule 1.

BTW2, "SMET" is used in the text before its expansion in section 9.1.1 (first 
use in section 4.1.1).

I still hope that the above email helps improving this document,

Regards

-éric


From: Eric Vyncke 
Date: Thursday, 28 October 2021 at 13:49
To: "Mankamana Mishra (mankamis)" , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 
"slitkows.i...@gmail.com" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)

Hello Mankamana,

Thank you for your constructive reply, please see below for EV> as I am afraid 
that your answers do not address completely my concerns.

Regards

-éric

From: "Mankamana Mishra (mankamis)" 
Date: Monday, 25 October 2021 at 20:26
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 
"slitkows.i...@gmail.com" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)

Hi Eric,
Thanks for comment. Please find inline comment for blocking disucss .

Mankamana

From: Éric Vyncke via Datatracker 
Date: Wednesday, October 20, 2021 at 1:28 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with 
DISCUSS and COMMENT)
É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 ?
Mankamana :  This draft covers what is EVPN related procedures. IGMP / MLD 
packets are generated by multicast host. And this document does not define any 
procedure about what needs to be done at host. Host is not even aware of 
presense of EVPN
EV> AFAIK, MLD/IGMP packets are also generated by routers and not only by 
hosts, but this is a detail.
EV> More important in my eyes: when one MLD/IGMP proxy receives some 
information via BGP, it also needs to forward the recreated MLD/IGMP locally to 
the attached hosts in order to be transparent. And I strongly believe that a 
short section on the document should describe the process. Hence keeping my 
blocking DISCUSS on this point.

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.
Mankamana : Since this draft transport all Valid IGMP / MLD join over BGP. It 
does not differentiate between different group range. All verification and 
handeling would be still IGMP / MLD router responsibility, so I do not think we 
would need to mention any of this.
EV> thank you for the confirmation, I still believe though that this is worth 
mentioning in the text in one sentence.
EV> I will 'degrade' this blocking DISCUSS into a non-blocking DISCUSS anyway.

-- Abstract --
While this point 

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

[Eric Vyncke (evyncke)]

Hello Mankamana,

Thank you for your constructive reply, please see below for EV> as I am afraid 
that your answers do not address completely my concerns.

Regards

-éric

From: "Mankamana Mishra (mankamis)" 
Date: Monday, 25 October 2021 at 20:26
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 
"slitkows.i...@gmail.com" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)

Hi Eric,
Thanks for comment. Please find inline comment for blocking disucss .

Mankamana

From: Éric Vyncke via Datatracker 
Date: Wednesday, October 20, 2021 at 1:28 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with 
DISCUSS and COMMENT)
É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 ?
Mankamana :  This draft covers what is EVPN related procedures. IGMP / MLD 
packets are generated by multicast host. And this document does not define any 
procedure about what needs to be done at host. Host is not even aware of 
presense of EVPN
EV> AFAIK, MLD/IGMP packets are also generated by routers and not only by 
hosts, but this is a detail.
EV> More important in my eyes: when one MLD/IGMP proxy receives some 
information via BGP, it also needs to forward the recreated MLD/IGMP locally to 
the attached hosts in order to be transparent. And I strongly believe that a 
short section on the document should describe the process. Hence keeping my 
blocking DISCUSS on this point.

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.
Mankamana : Since this draft transport all Valid IGMP / MLD join over BGP. It 
does not differentiate between different group range. All verification and 
handeling would be still IGMP / MLD router responsibility, so I do not think we 
would need to mention any of this.
EV> thank you for the confirmation, I still believe though that this is worth 
mentioning in the text in one sentence.
EV> I will 'degrade' this blocking DISCUSS into a non-blocking DISCUSS anyway.

-- 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.
Mankamana : Added MLD in abstract. But later in terminology, it has been 
mentioned that even though we have used term IGMP, its valid for MLD too. For 
better redability, MLD has been not used in rest of document.
EV> Thank you for fixing the abstract (I will clear my DISCUSS on this point), 
but, honestly using "IGMP" rather than "MLD" in 2021... this smells like a 
museum to my taste.

--
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.
Anycast multicast is well known , and do not think there is need to mention it 
more in document about it.
EV> rather than assuming that it is well-known, I strongly suggest to add a 
reference to this term or add it in th

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

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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Jorge

Perfect !

As soon as the next revision is uploaded with this change, then I am changing 
my ballot from DISCUSS to NO OBJECTION.

While the resolution took some time, I have appreciated our discussions :-)

Regards

-éric


From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Wednesday, 6 October 2021 at 18:56
To: Eric Vyncke , The IESG , 
"draft-ietf-bess-evpn-proxy-arp...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , "Bocci, Matthew (Nokia 
- GB)" , "jeanmichel.com...@orange.com" 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Eric,

Thanks for getting back.
About your comment:

   -  The 'reply' option implies that the PE ignores the unknown
  options and replies with NA messages, assuming a successful
  lookup on the Proxy-ND table.

EV4> what is the behavior when the ‘reply’ option is selected and there is no 
successful lookup ?  I guess it is ‘forward’ but this is worth specifying in 
the text.


That’s another good point. I’ll add the following and if you are okay with it 
we’ll publish revision 16 with this change:

OLD:

   -  The 'reply' option implies that the PE ignores the unknown
  options and replies with NA messages, assuming a successful
  lookup on the Proxy-ND table.

NEW:

   -  The 'reply' option implies that the PE ignores the unknown
  options and replies with NA messages, assuming a successful
  lookup on the Proxy-ND table. An unsuccessful lookup will result
  on a ‘forward’ behavior (i.e., flood the NS message based on
  the MAC DA.


Please let me know if you are ok with it.

Thank you!
Jorge

From: Eric Vyncke (evyncke) 
Date: Wednesday, October 6, 2021 at 5:17 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , The 
IESG , draft-ietf-bess-evpn-proxy-arp...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Bocci, Matthew (Nokia - 
GB) , jeanmichel.com...@orange.com 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)
Hello Jorge

As I am back from vacations, it is time to write a reply. We are now very close 
to a revision which would allow me to clear my blocking DISCUSS. Look below for 
EV4> (which is trivial to fix)

Big thank you for also addressing/replying to my non-blocking COMMENT points 
;-) (I have elided the text about them)

Regards,

-éric


From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Thursday, 23 September 2021 at 09:35
To: The IESG , "draft-ietf-bess-evpn-proxy-arp...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , "Bocci, Matthew (Nokia 
- GB)" , "jeanmichel.com...@orange.com" 
, Eric Vyncke 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Eric,

Thank you very much once again for your thorough review, it helped a lot.

Please see my comments and resolutions below with [jorge3]. Revision 15 
incorporates all the changes.
Assuming this can clear your DISCUSS and COMMENTs (please let us know 
otherwise), I think the document also addresses Erik Kline’s comments, and it 
is now ready to go.

Thanks.
Jorge


From: Eric Vyncke (evyncke) 
Date: Tuesday, September 14, 2021 at 2:50 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , The 
IESG , draft-ietf-bess-evpn-proxy-arp...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Bocci, Matthew (Nokia - 
GB) , jeanmichel.com...@orange.com 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)
Hello Jorge,

Sorry for belated reply… IETF week and some holidays were on the path...

The -14 revision has vastly improved the document and has addressed the 
majority of my points. There are anyway still one open blocking DISCUSS point 
and three COMMENT points (but feel free to ignore them).

See in the elided text for EV3>

Regards,

-éric



--
DISCUSS:
--
== DISCUSS ==


-- Section 3.2 --
Why not flooding to all other PEs the ARP/NS with unknown options ? It would be
safer.
[jorge] yes, the new text is as follows, let me know please:

   f.  A PE MUST only reply to ARP-Request and NS messages with the

   format specified in [RFC0826] and [RFC4861] respectively.

   Received ARP-Requests and NS messages with unknown options SHOULD

   be either forwarded (as unicast packets) to the owner of the

   requested IP (assuming the MAC is known in the Proxy-ARP/ND table

   and BD) or discarded.  An option to flood ARP-Requests/NS

   messages with unknown options MAY be used.  The operator should

   assess if flooding those unknown options may b

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Hello Jorge

As I am back from vacations, it is time to write a reply. We are now very close 
to a revision which would allow me to clear my blocking DISCUSS. Look below for 
EV4> (which is trivial to fix)

Big thank you for also addressing/replying to my non-blocking COMMENT points 
;-) (I have elided the text about them)

Regards,

-éric


From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Thursday, 23 September 2021 at 09:35
To: The IESG , "draft-ietf-bess-evpn-proxy-arp...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , "Bocci, Matthew (Nokia 
- GB)" , "jeanmichel.com...@orange.com" 
, Eric Vyncke 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Eric,

Thank you very much once again for your thorough review, it helped a lot.

Please see my comments and resolutions below with [jorge3]. Revision 15 
incorporates all the changes.
Assuming this can clear your DISCUSS and COMMENTs (please let us know 
otherwise), I think the document also addresses Erik Kline’s comments, and it 
is now ready to go.

Thanks.
Jorge


From: Eric Vyncke (evyncke) 
Date: Tuesday, September 14, 2021 at 2:50 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , The 
IESG , draft-ietf-bess-evpn-proxy-arp...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Bocci, Matthew (Nokia - 
GB) , jeanmichel.com...@orange.com 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)
Hello Jorge,

Sorry for belated reply… IETF week and some holidays were on the path...

The -14 revision has vastly improved the document and has addressed the 
majority of my points. There are anyway still one open blocking DISCUSS point 
and three COMMENT points (but feel free to ignore them).

See in the elided text for EV3>

Regards,

-éric



--
DISCUSS:
--
== DISCUSS ==


-- Section 3.2 --
Why not flooding to all other PEs the ARP/NS with unknown options ? It would be
safer.
[jorge] yes, the new text is as follows, let me know please:

   f.  A PE MUST only reply to ARP-Request and NS messages with the

   format specified in [RFC0826] and [RFC4861] respectively.

   Received ARP-Requests and NS messages with unknown options SHOULD

   be either forwarded (as unicast packets) to the owner of the

   requested IP (assuming the MAC is known in the Proxy-ARP/ND table

   and BD) or discarded.  An option to flood ARP-Requests/NS

   messages with unknown options MAY be used.  The operator should

   assess if flooding those unknown options may be a security risk

   for the EVPN BD.  An administrative option to control this

   behavior ('unicast-forward', 'discard' or 'forward') SHOULD be

   supported.  The 'unicast-forward' option is described in

   Section 3.4.

EV> please note that the ‘forward’ behavior does not seem to be listed as a 
sub-function
[jorge2] Not listed as a specific sub-function but ‘forward’ is the flooding 
behavior when the ARP-Request/NS is received and  the lookup in the 
proxy-ARP/ND table is unsuccessful, as described in section 3. I changed the 
bullet f) a bit for clarity:
   f.  For Proxy-ARP, a PE MUST only reply to ARP-Request with the
   format specified in [RFC0826].  For Proxy-ND, a PE MUST reply to
   NS messages with the format and options specified in [RFC4861],
   and MAY reply to NS messages containing other options.  Received
   NS messages with unknown options MAY be forwarded (as unicast
   packets) to the owner of the requested IP (assuming the MAC is
   known in the Proxy-ARP/ND table and BD).  An administrative
   choice to control the behavior for received NS messages with
   unknown options ('unicast-forward', 'discard' or 'forward') MAY
   be supported.  The 'forward' option implies flooding the NS message
   based on the MAC DA.  The 'unicast-forward' option is described
   in Section 3.4.  If 'discard' is available, the operator should
   assess if flooding NS unknown options may be a security risk for
   the EVPN BD (and is so, enable 'discard'), or if, on the
   contrary, not forwarding NS unknown options may disrupt
   connectivity.

EV2> the text should also state that NS messages MAY be ‘discarded’ to be 
consistent with the administrative choice.
EV2> in the ‘MAY be forward’, the text is only about unicast while the 
administrative choice includes the ‘forward’ / flooding
EV2> the administrative choice should also include ‘reply’ (even if I really 
dislike this choice as it can break badly things)
EV2> strongly suggest to add a ‘SHOULD forward’ or 

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Hello Jorge,

Sorry for belated reply… IETF week and some holidays were on the path...

The -14 revision has vastly improved the document and has addressed the 
majority of my points. There are anyway still one open blocking DISCUSS point 
and three COMMENT points (but feel free to ignore them).

See in the elided text for EV3>

Regards,

-éric



--
DISCUSS:
--


== DISCUSS ==


-- Section 3.2 --
Why not flooding to all other PEs the ARP/NS with unknown options ? It would be
safer.
[jorge] yes, the new text is as follows, let me know please:

   f.  A PE MUST only reply to ARP-Request and NS messages with the

   format specified in [RFC0826] and [RFC4861] respectively.

   Received ARP-Requests and NS messages with unknown options SHOULD

   be either forwarded (as unicast packets) to the owner of the

   requested IP (assuming the MAC is known in the Proxy-ARP/ND table

   and BD) or discarded.  An option to flood ARP-Requests/NS

   messages with unknown options MAY be used.  The operator should

   assess if flooding those unknown options may be a security risk

   for the EVPN BD.  An administrative option to control this

   behavior ('unicast-forward', 'discard' or 'forward') SHOULD be

   supported.  The 'unicast-forward' option is described in

   Section 3.4.

EV> please note that the ‘forward’ behavior does not seem to be listed as a 
sub-function
[jorge2] Not listed as a specific sub-function but ‘forward’ is the flooding 
behavior when the ARP-Request/NS is received and  the lookup in the 
proxy-ARP/ND table is unsuccessful, as described in section 3. I changed the 
bullet f) a bit for clarity:
   f.  For Proxy-ARP, a PE MUST only reply to ARP-Request with the
   format specified in [RFC0826].  For Proxy-ND, a PE MUST reply to
   NS messages with the format and options specified in [RFC4861],
   and MAY reply to NS messages containing other options.  Received
   NS messages with unknown options MAY be forwarded (as unicast
   packets) to the owner of the requested IP (assuming the MAC is
   known in the Proxy-ARP/ND table and BD).  An administrative
   choice to control the behavior for received NS messages with
   unknown options ('unicast-forward', 'discard' or 'forward') MAY
   be supported.  The 'forward' option implies flooding the NS message
   based on the MAC DA.  The 'unicast-forward' option is described
   in Section 3.4.  If 'discard' is available, the operator should
   assess if flooding NS unknown options may be a security risk for
   the EVPN BD (and is so, enable 'discard'), or if, on the
   contrary, not forwarding NS unknown options may disrupt
   connectivity.

EV2> the text should also state that NS messages MAY be ‘discarded’ to be 
consistent with the administrative choice.
EV2> in the ‘MAY be forward’, the text is only about unicast while the 
administrative choice includes the ‘forward’ / flooding
EV2> the administrative choice should also include ‘reply’ (even if I really 
dislike this choice as it can break badly things)
EV2> strongly suggest to add a ‘SHOULD forward’ or ‘This document RECOMMEND to 
‘forward’’

EV3> an answer or a new text for the above is all that remains from my previous 
DISCUSS points.

--
COMMENT:
--



-- Section 2.1 --
I would have assumed that the multicast nature of IPv6 address resolution would
cause more problems than IPv4 ARP. The use of link-local multicast groups do
not usually help as MLD snooping is often disabled in switches for link-local.
Not to mention that there could be more IPv6 addresses per node than IPv4
address and IPv6 addresses keep changing. Do the authors have data to back this
section ?
[jorge] I added a sentence in that respect. As a side note, one of the 
references that we include claims that the use of SN-multicast addresses in NS 
messages is actually better than broadcast in ARP, given that SN-multicast IP 
Das can be easily identified and discarded at the receiving CEs (assuming that 
the PEs do not have MLD snooping enabled) 
https://delaat.net/rp/2008-2009/p23/report.pdf

EV> I failed to see the added sentence in -13
EV> the URL you wrote above does not work anymore... Also, quite an old 
reference
[jorge2] you’re right - I removed the reference since it no longer exists. 
Although illustrative, It is not important to understand the text anyway. The 
paragraph about mcast is this one:
The issue might be better in IPv6 routers if MLD-snooping was
   enabled, since ND uses SN-multicast address in NS messages; however,
   ARP uses broadcast and has to be processed by all the routers in the
   network.  Some routers may also be configured to bro

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Jorge,

Another sorry for the belated reply…

See below for EV2> based on your reply and on the -14. I have also removed 
everything where we are in agreement.

As my review/ballot is dated January, I will review it again and update my 
ballot accordingly.

Regards

-éric

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Tuesday, 8 June 2021 at 12:50
To: Eric Vyncke , The IESG , 
"draft-ietf-bess-evpn-proxy-arp...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , "Bocci, Matthew (Nokia 
- GB)" , "jeanmichel.com...@orange.com" 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Eric,

Sorry for my belated reply to yours too!

Thanks again for taking the time to review our response. We just published 
revision 14.
See my comments in-line with [jorge2] to the outstanding points (I believe I 
addressed all pending points), and please let me know if that is enough to 
clear your DISCUSS.

Thanks!
Jorge


From: Eric Vyncke (evyncke) 
Date: Monday, May 3, 2021 at 4:37 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , The 
IESG 
Cc: draft-ietf-bess-evpn-proxy-arp...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Bocci, Matthew (Nokia - 
GB) , jeanmichel.com...@orange.com 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)
Hello Jorge,

Sorry for belated reply… Your email was kind of lost in my post-IETF-110 filled 
in-tray...

See below for EV> (for the many comments, as you have addressed them, I replied 
nothing).

Once I am clear about how normal DAD (i.e., non optimized by your document) 
continues to work, then I am clearing my DISCUSS. So, more explanations by 
email or in the I-D are welcome.

Regards

-éric


From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Thursday, 18 March 2021 at 09:04
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-proxy-arp...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , "Bocci, Matthew (Nokia 
- GB)" , "jeanmichel.com...@orange.com" 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Éric,

Thanks for this, it is very useful. Please see my comments in-line with [jorge].
We just published a revision, addressing yours and all the comments received in 
all the reviews.

Thanks again!
Jorge

From: Éric Vyncke via Datatracker 
Date: Thursday, January 21, 2021 at 3:13 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-proxy-arp...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Bocci, Matthew (Nokia - 
GB) , Bocci, Matthew (Nokia - GB) 
, jeanmichel.com...@orange.com 

Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with 
DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-proxy-arp-nd-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/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/



--
DISCUSS:
--

Thank you for the work put into this document. This system could indeed be very
useful but I am afraid that this is a very complex system especially for IPv6
NDP.

Minor regret in the shepherd write-up as the WG summary did not include any
comment on the WG consensus.

Thanks to Jean-Michel Combes for its Internet directorate review at:
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-proxy-arp-nd-11-intdir-telechat-combes-2021-01-20/
as Jean-Michel added some important comments, please review them as well as I
support them especially those around DAD that should be a blocking DISCUSS
point.

I also second Erik Kline's DISCUSS points.

Question to the authors and BESS WG chairs: was this document submitted to a
6MAN/V6OPS WGs review ? This is where all IPv6 experts live :-)
EV2> Still waiting for a reply on this (mainly to update the processes for 
similar documents), nothing is blocking for this one.


Please find below some blocking DISCUSS points, some non-blocking COMMENT
points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

Would RFC 8929 be enough to solve the problem ?
[jorge] I found RFC8929 an interesting reading, thanks for the reference. 
However, unless I’m missing something the use-case is very different.
It seems RFC8929 tries to reduce broadcast domains by using

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-datacenter-gateway-10: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Adrian,

Thank you for your reply. As you know all my comments are non-blocking, please 
have a look below for EV>

Regards,

-éric

-Original Message-
From: Adrian Farrel 
Organization: Old Dog Consulting
Reply-To: "adr...@olddog.co.uk" 
Date: Monday, 17 May 2021 at 16:21
To: Eric Vyncke , 'The IESG' 
Cc: "draft-ietf-bess-datacenter-gate...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 'Matthew Bocci' 

Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-bess-datacenter-gateway-10: (with COMMENT)

Hi Eric,

| Thank you for the work put into this document.
|
| I support John Scudder's first DISCUSS point.

Fair enough.

What did you think of my response to John

EV> I rely on the RTG-AD John on whether the resolution below satisfies him 
(and it seems so based on the email thread)

>> DISCUSS:
>>
>> 1. There’s surprisingly little in this document that seems to be 
SR-specific
>> (and what there is, has some problems, see below). Is there some reason 
you
>> rule out interconnecting domains using other tunneling technologies? I 
ask this
>> question first because if the answer were to be “oh huh, we don’t need 
to make
>> this SR-specific after all” some of the other things I’m asking about 
might go
>> away.
>
> I'm sorry this isn't clear, but the use of other tunnelling technologies 
is very much
> in scope. As the Introduction says:
>
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.
>
> SR is used to identify the tunnels and provide end-to-end SR paths 
because the
> ingress and egress domains are SR domains, and the objective is to 
provide an
> end-to-end SR path.
>
> So we are not "making this SR aware" so much as enabling "SR-over-foo" 
using
> SIDs to identify the path segments that are tunnels.
>
> I don't know how to make this clearer except maybe using some red paint. 
We
> would write...
>
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.  That is, the
>   Ingress and Egress SR Domains can be connected by tunnels across a
>   variety of technologies.  This document describes how SR identifiers
>   (SIDs) are used to identify the paths between the Ingress and Egress
>   and the techniques in this document apply to routes of all AFI/SAFIs.


| Please find below some non-blocking COMMENT points (but replies
| would be appreciated), and some nits.
|
| == COMMENTS ==
|
| -- Section 3 --
| How will the GW identifiers be unique across all interconnected SR 
domains ?
| Section 9 is rather hand waving.

There are two issues to be resolved:
1. How will all interconnected SR sites (formerly called domains) use 
different site identifiers?
2. How will all gateways to the same site consistently use the same 
identifier?

Just like the mechanisms used to assign many other things in networking (IP 
addresses, AS numbers, VPN IDs, ...) there may be many approaches available 
(dedicated protocols, piggy-backing on other protocols, management protocols, 
manual configuration).

Not sure why this spec needs to be responsible for defining those 
distribution/configuration/coordination mechanisms.

EV> actually, you have just recommended/suggested one method: static 
configuration by human/SDN controllers

Section 9 makes it very clear what result must be achieved, and observes 
that we are not introducing a new problem to the BGP world.

Could we make it clearer that the operator is responsible for getting this 
right?

| -- Section 10 --
| Is there any reason why the doc shepherd is not acknowledged ?

Of course, we love our shepherd. 
Matthew, as WG chair, pushed the right people to do reviews, and also 
pushed the right buttons to advance the document.
As shepherd, Matthew wrote: I reviewed Version 8 of the draft. I have no 
significant comments on the draft. 

The Acknowledgements section historically thanks people whose comments have 
helped shape or improve the contents of the document.

EV> FYI, the IESG wants to provide incentive for being a doc shepherd or a 
directorate reviewer. I.e., the shepherd is expected to do a lot of leg work 
for the document and a serious in-depth review by a directorate reviewer is 
important even if the review can be summarized as a simple 'good to go', the 
effort is worthwhile IMHO (even is the quality of reviews can vary)

| == NIT

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Alvaro

Thank you for the added piece of information. I am clearing my DISCUSS tomorrow 
(past midnight here).

Regards

-éric

-Original Message-
From: iesg  on behalf of Alvaro Retana 

Date: Monday, 17 May 2021 at 23:34
To: Éric Vyncke via Datatracker , Eric Vyncke 
, The IESG 
Cc: Matthew Bocci , "Mankamana Mishra (mankamis)" 
, "bess-cha...@ietf.org" , 
"draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org" 
, "bess@ietf.org" 

Subject: Re: [bess] Éric Vyncke's Discuss on 
draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)

Éric:

Hi!

MSDP (from 2003) is an IPv4-only protocol.

Also, take a look at rfc4611/BCP121 (MSDP Deployment Scenarios) which
mentions other IPv6 alternatives which makes any extension of MSDP
unnecessary.


Alvaro.


On May 17, 2021 at 2:10:13 AM, Éric Vyncke wrote:

> == DISCUSS ==
> While I am an expert neither in multicast not in VPN, I wonder why this
> document is only about IPv4 and not a single word is written about IPv6.


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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Hello Jorge,

Sorry for belated reply… Your email was kind of lost in my post-IETF-110 filled 
in-tray...

See below for EV> (for the many comments, as you have addressed them, I replied 
nothing).

Once I am clear about how normal DAD (i.e., non optimized by your document) 
continues to work, then I am clearing my DISCUSS. So, more explanations by 
email or in the I-D are welcome.

Regards

-éric


From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Thursday, 18 March 2021 at 09:04
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-proxy-arp...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , "Bocci, Matthew (Nokia 
- GB)" , "jeanmichel.com...@orange.com" 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Éric,

Thanks for this, it is very useful. Please see my comments in-line with [jorge].
We just published a revision, addressing yours and all the comments received in 
all the reviews.

Thanks again!
Jorge

From: Éric Vyncke via Datatracker 
Date: Thursday, January 21, 2021 at 3:13 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-proxy-arp...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Bocci, Matthew (Nokia - 
GB) , Bocci, Matthew (Nokia - GB) 
, jeanmichel.com...@orange.com 

Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with 
DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-proxy-arp-nd-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/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/



--
DISCUSS:
--

Thank you for the work put into this document. This system could indeed be very
useful but I am afraid that this is a very complex system especially for IPv6
NDP.

Minor regret in the shepherd write-up as the WG summary did not include any
comment on the WG consensus.

Thanks to Jean-Michel Combes for its Internet directorate review at:
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-proxy-arp-nd-11-intdir-telechat-combes-2021-01-20/
as Jean-Michel added some important comments, please review them as well as I
support them especially those around DAD that should be a blocking DISCUSS
point.

I also second Erik Kline's DISCUSS points.

Question to the authors and BESS WG chairs: was this document submitted to a
6MAN/V6OPS WGs review ? This is where all IPv6 experts live :-)

Please find below some blocking DISCUSS points, some non-blocking COMMENT
points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

Would RFC 8929 be enough to solve the problem ?
[jorge] I found RFC8929 an interesting reading, thanks for the reference. 
However, unless I’m missing something the use-case is very different.
It seems RFC8929 tries to reduce broadcast domains by using MLSNs where each 
link is its own broadcast domain. In EVPN BDs, the idea is reduce the control 
plane Broadcast/Multicast flooding among PEs of the same BD by replacing them 
with BGP EVPN routes. For ARP/ND, this basically means we learn at the ingress 
PE by snooping ARP/NAs and advertise the entries in EVPN MAC/IP routes so that 
the egress PE learns ARP/ND entries, and can reply to its local 
ARP-Requests/NS. Also in RFC8929, even for the bridging proxy, it seems that 
the proxy appears as an IPv6 host on the backbone, which is not the case in 
this document. Another difference is that the proxy in RFC8929 uses only ND 
messages to register bindings and in our document, we also use static entries 
and EVPN messages (in addition to snooped ARP and NA messages).
Please let me know if you see it otherwise.

EV> the use case is indeed different but the handling of new ND code should be 
the same or similar even if the ‘transport/sharing’ of information is 
different. Moreover RFC 8929 has been published by an IPv6-heavy WG.


-- Section 3 --
"A Proxy-ARP/ND implementation MAY support all those sub-functions or only a
subset of them.", I am afraid that it is mandatory that the reply and
duplicate-ip must be coupled: either both of them are active or none of them
are active else the system allows for duplicate IP addresses.
[jorge] the new text is as follows, let me know if it is okay. Note that the 
duplicate ip detection on the PEs is new in this document, and we didn’t want 
to make it mandatory we allow backwards compatibility with RFC7432 EVPN PEs 
that do proxy-ARP/ND.

   A Proxy-ARP/ND implementation MUST at least sup

Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

And as  shared John’s concern, the new text looks like fixing the problem

Thank for having updated the document

-éric

From: iesg  on behalf of John Scudder 

Date: Monday, 12 April 2021 at 19:39
To: Donald Eastlake 
Cc: Matthew Bocci , "bess-cha...@ietf.org" 
, "draft-ietf-bess-evpn-oam-req-fr...@ietf.org" 
, The IESG , 
"bess@ietf.org" 
Subject: Re: John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: 
(with DISCUSS and COMMENT)

Thanks for hopping threads, I shoulda caught that last one. Your proposed 
change looks fine, I’ll remove my DISCUSS in anticipation of you issuing a new 
version. (One nit on your new text, “in order maximize” should be “in order to 
maximize”.)

—John


On Apr 12, 2021, at 1:03 PM, Donald Eastlake 
mailto:d3e...@gmail.com>> wrote:


[External Email. Be cautious of content]


Hi,

On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker 
mailto:nore...@ietf.org>> wrote:
>
> John Scudder has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-08: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> Section 2.3:
>
>EVPN Network OAM mechanisms MUST provide in-band monitoring
>capabilities. As such, OAM messages MUST be encoded so that they
>exhibit identical entropy characteristics to data traffic in order
>that they share the same fate.
>
> It’s not obvious to me what you mean by “identical entropy characteristics to
> data traffic”. Surely, different flows may have different entropy
> characteristics, so, *which* data traffic? Similarly, with which data traffic
> are you saying the OAM messages must share fate?

I guess when you changed your COMMENT to a DISCUSS it creates a new thread so I 
should reply here as I did to this when it was a COMMENT:

How about something more like:
EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities. OAM 
messages SHOULD be encoded so that they exhibit similar entropy characteristics 
to data traffic in order maximize the fate sharing between OAM and data.

> --
> COMMENT:
> --
>
> Thanks for the clear and readable document. I have one nit and one question.
>
> 1. Section 1, nit:
>
> “EVPN is an Layer 2” s/an/a/

OK.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

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

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

[Eric Vyncke (evyncke)]

Donald,

Thank you for your reply as well as for answering all the questions. I like 
your suggestion about MA/MEP/MIP.

About the last point (synthetic traffic or iOAM), while I understand the point 
that OAM should work in the absence of actual traffic (pretty obvious indeed), 
I am still ambivalent whether this document should only be about synthetic 
traffic without being open to other OAM techniques.

Regards

-éric

-Original Message-
From: Donald Eastlake 
Date: Thursday, 8 April 2021 at 00:05
To: Eric Vyncke 
Cc: The IESG , "draft-ietf-bess-evpn-oam-req-fr...@ietf.org" 
, "bess-cha...@ietf.org" 
, BESS , Matthew Bocci 

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

Hi Éric,

On Wed, Apr 7, 2021 at 4:14 AM Éric Vyncke via Datatracker
 wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated).
>
> I hope that this helps to improve the document,
>
> Regards,
> -éric
>
> == COMMENTS ==
>
> Minor regret for a doc shepherd write-up, which is dated 9 months ago...
>
> -- Section 1 --
> Introducing C-MAC and B-MAC could be useful for the reader.

C-MAC is Customer/Client MAC address and B-MAC is Backbone MAC address
as further specified in RFC 7623. These can be spelled out and a
reference to RFC 7623 (which is already listed in the References for
this draft) added.

> -- Section 1.3 --
> Slighlty puzzled by MA/MEP/MIP as those are only about the M of OAM. 
Should
> those be OAMA, OAMEP, OAMIP ? Or at least should there be some 
explanations ?

MA/MEP/MIP are all terms used in CFM (Connectivity Fault Management)
which is specified in 802.1Q. There could be some wording adjustment
to clarify this. For example, saying that they are "part of" Service
OAM rather than implying they might be all of it.

> -- Section 2.2 --
> I must confess my lack of knowledge about CFM frames but I am puzzled by
> "snooping on CFM frames and advertising them to remote PEs as a MAC/IP" 
1) if
> the CFM frame are not IP, then how can it be advertised in a MAC/IP ? 
(i.e.,
> the CE may not use IP at all) 2) if the CFM frame are IP, then which 
version of
> IP ? and how to recognize them ? Or did I miss something obvious ?

CFM frames are not IP. However, the EVPN MAC/IP Advertisement route is
quite flexible and includes a length for the IP address. As stated in
RFC 7432 "By default, the IP Address Length field is set to 0, and the
IP Address field is omitted from the route." If you do know an IP
address and want to advertise it, then the length is 32 or 128, as
appropriate, and the IP address is included.

> -- Section 3.1.2.1 --
> Does this section cover OAM designed by other WG ? E.g.,
> draft-ietf-ippm-ioam-data or draft-ietf-6man-ipv6-alt-mark
>
> -- Section 3.2.1 --
> Mostly the same comment as for 3.1.2.1, this section is only about 
synthetic
> traffic injection.

EVPN Network OAM could include OAM designed by other WGs including
ioam. However, in my opinion the mandatory capabilities should be
available even in the absence of real traffic.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

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

Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Greg,

Thank you very much for addressing all my points were applicable. I am changing 
my ABSTAIN into a NO OBJECTION (even if it does not really matter)

Regards

-éric

From: iesg  on behalf of Greg Mirsky 

Date: Monday, 21 December 2020 at 01:56
To: Eric Vyncke 
Cc: Stephane Litkowski , "bess-cha...@ietf.org" 
, The IESG , BESS , 
"draft-ietf-bess-mvpn-fast-failo...@ietf.org" 

Subject: Re: Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: 
(with COMMENT)

Hi Eric,
apologies for the belated response. Please find my answers below in-lined 
tagged by GIM>>.

Regards,
Greg

On Wed, Dec 16, 2020 at 2:05 AM Éric Vyncke via Datatracker 
mailto:nore...@ietf.org>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: 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/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-mvpn-fast-failover/



--
COMMENT:
--

Thank you for the work put into this document.

I have balloted ABSTAIN in the sense of "I oppose this document but understand
that others differ and am not going to stand in the way of the others." because
of the use outside of a node of the IPv4-mapped IPv6 addresses in section
3.1.6.1. A reply on this topic will be welcome.

Stéphane in his doc shepherd's write up states that no implementation is known
for a document born in 2008... Does the IETF really want to have this on the
proposed standards track ?

Please find below my ABSTAIN point, some non-blocking COMMENT points (but
replies would be appreciated), and one nits.

I hope that this helps to improve the document,

Regards,

-éric

== ABSTAIN ==
-- Section 3.1.6.1 --
I appreciate that the BFD WG relies on 
":::127.0.0.0/104" but those
IPv4-mapped IPv6 addresses are assumed to never leave a node and should never
be transmitted over the Internet (see
https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my
ABSTAIN. As the inner packet is sent over a tunnel, why not using the a
link-local address or the ff02::1 link-local multicast group ?
GIM>> This text has been updated. Please let me know if the new text is 
acceptable:
NEW TEXT:
   o  when transmitting BFD Control packets MUST set the IP destination
  address of the inner IP header to the internal loopback address
  127.0.0.1/32 for IPv4 [RFC1122].  For IPv6, it MUST 
use the
  loopback address ::1/128 [RFC4291].

== COMMENTS ==

-- Section 2.3 --
The use of "upstream" and "Upstream" could be confusing... The latter could
have been "Upstream PE/ABSR" (often used later in the document) or "ingress
node"
GIM>> We've tried to clarify the difference in the Terminology section. As I 
can see from grepping the document, it consistently uses "Upstream PE" 
(Upstream ASBR is used once).

-- Section 3.1.6 --
Could the "BFD Discreminator" attribute be used for other purpose than this
document? If so, then why not specifying it in *another* document?

Should this document clearly state that it does not define any TLV ?
GIM>> Added a note in Section 7.3 BFD Discriminator Optional TLV Type:
NEW TEXT:
No optional TLV types defined at the creation of the registry.

== NITS ==

As I am probably not the only reader have difficulties to remember RFC contents
by their number, may I suggest to prefix the RFC numbers with their titles ?
Esp in the introduction ;-)
GIM>> I understand the challenge that manner of using references might present. 
In the Abstract RFC 8562 is referenced by both number and its full title. I'm 
concerned that doing that in the body of a document might inflate the size. I 
use HTMLized version that conveniently links the reference and the referenced 
document.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[Eric Vyncke (evyncke)]

Jeffrey

This would be quite positive to post this on the BESS list like you just did ;-)

And, Stéphane, I agree that the topic of "lack of implementations for a 
standards track document" is wider than this document: it was really a comment 
of mine and not one asking for a reply (but yours was appreciated)

-éric

-Original Message-
From: "Jeffrey (Zhaohui) Zhang" 
Date: Wednesday, 16 December 2020 at 13:50
To: "slitkows.i...@gmail.com" , Eric Vyncke 
, 'The IESG' , "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Cc: "bess-cha...@ietf.org" , 
"draft-ietf-bess-mvpn-fast-failo...@ietf.org" 
, "bess@ietf.org" 
Subject: RE: [bess]  Éric Vyncke's Abstain on 
draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

Ah. Perhaps vendors forgot/neglected to respond on the implementation 
question for this particular spec, I know of two implementations.

Jeffrey

-Original Message-
From: BESS  On Behalf Of slitkows.i...@gmail.com
Sent: Wednesday, December 16, 2020 5:39 AM
To: 'Éric Vyncke' ; 'The IESG' 
Cc: bess-cha...@ietf.org; draft-ietf-bess-mvpn-fast-failo...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] Éric Vyncke's Abstain on 
draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[External Email. Be cautious of content]


Hi Eric,

Speaking as BESS WG chair, you raised a very valid point on the publication 
of documents that have no implementation (or plan of implementation). This is 
also a concern that I have in general, as we cannot really prove that a 
technology/specification is working properly if it hasn't been implemented.
I think the discussion is a bit orthogonal to this particular document.
In the routing area, each WG is free to have its own policy regarding 
implementations. In BESS, the WG decided that there will be an implementation 
poll then if there is no implementation, and if WG is still fine progressing 
the doc without an implementation, the document will continue until 
publication. Good or bad that could be discussed but this is the WG consensus 
(it was there before I took over the chair seat). This policy differs across 
WGs.
I don't think that the date of the doc really matters, even if the doc was 
more recent, nothing says that there will be an implementation in future, so 
situation will be the same. I personally don't like having non implemented 
specs but it's not just up to me and again this goes beyond just this document.

Brgds,

Stephane

-Original Message-
From: Éric Vyncke via Datatracker 
Sent: mercredi 16 décembre 2020 11:06
To: The IESG 
Cc: draft-ietf-bess-mvpn-fast-failo...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Stephane Litkowski ; 
slitkows.i...@gmail.com
Subject: Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: 
(with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcPs169tg$
for more information about IESG 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-mvpn-fast-failover/__;!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcD1j6hff$



--
COMMENT:
--

Thank you for the work put into this document.

I have balloted ABSTAIN in the sense of "I oppose this document but 
understand that others differ and am not going to stand in the way of the 
others." because of the use outside of a node of the IPv4-mapped IPv6 addresses 
in section 3.1.6.1. A reply on this topic will be welcome.

Stéphane in his doc shepherd's write up states that no implementation is 
known for a document born in 2008... Does the IETF really want to have this on 
the proposed standards track ?

Please find below my ABSTAIN point, some non-blocking COMMENT points (but 
replies would be appreciated), and one nits.

I hope that this helps to improve the document,

Regards,

-éric

== ABSTAIN ==
-- Section 3.1.6.1 --
I appreciate that the BFD WG relies on ":::127.0.0.0/104" but those 
IPv4-mapped IPv6 addresses are assumed to never leave a node and should never 
be transmitted over the Internet (see 
https://urldefense.com/v3/__https://tools.ietf.org/html/rfc5156*section-2.2__;Iw!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcKQDD6CU$
 ). This is the cause of my ABST

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-na-flags-06: (with COMMENT)

[Eric Vyncke (evyncke)]

Jorge

Thank you for the prompt reply: I appreciate the explanation for the ‘missing’ 
bit always nice to hear such stories ;-)

Regards,

-éric

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Thursday, 17 September 2020 at 11:39
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-na-fl...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , "Bocci, Matthew (Nokia 
- GB)" , "rwe...@akamai.com" 
Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-na-flags-06: 
(with COMMENT)

Hi Éric,

Thank you very much for reviewing.
Please see in-line below.
Thanks.
Jorge


From: Éric Vyncke via Datatracker 
Date: Wednesday, September 16, 2020 at 12:19 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-na-fl...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Bocci, Matthew (Nokia - 
GB) , Bocci, Matthew (Nokia - GB) 
, rwe...@akamai.com 
Subject: Éric Vyncke's No Objection on draft-ietf-bess-evpn-na-flags-06: (with 
COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-na-flags-06: 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:
--

Thank you for the work put into this document. Even if I mainly rely on the
int-dir review (see below), I quickly reviewed the document and found it very
useful and readable.

Thanks to Ralf Weber who did the INT directory review, at
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-na-flags-05-intdir-lc-weber-2020-08-28/

Please find below a couple of non-blocking COMMENT and NIT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 2  --
For my curiosity sake, why bit 5 of the 'Flags field' is not described? I would
have naively assumed that all flags would be contiguous.
[Jorge] Sure. When flag I was added, “draft-rbickhart-evpn-ip-mac-proxy-adv” 
had been published and there were implementations using bit 5. That’s the 
reason why we had to move the flag I, to avoid collisions.


== NITS ==

-- Section 2 --
While it is specified that the reserved fields are set to 0, the usual 'and
ignored by the receiver' is not present.
[Jorge] good point. I’ll add it in the next revision.


When describing the 'Router Flag', I suggest s/belongs to a router. /belongs to
an IPv6 router./ even if fairly obvious
[Jorge] sure, added it for the next revision.




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

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Eric Vyncke (evyncke)]

Thank you Ali

The text should improve the quality of the document

Regards

-éric

-Original Message-
From: "Ali Sajassi (sajassi)" 
Date: Thursday, 3 September 2020 at 18:39
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , Zhaohui Zhang 

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

Hi Eric,

I add the following sentences in section 2 to provide further clarification 
to your point:
" It should be
   noted that if an IP-VRF in a NVE is configured for IPv6 and that NVE
   receives IPv4 traffic on the corresponding VLAN, then the IPv4
   traffic is treated as L2 traffic and it is bridged.  Also vise versa,
   if an IP-VRF in a NVE is configured for IPv4 and that NVE receives
   IPv6 traffic on the corresponding VLAN, then the IPv6 traffic is
   treated as L2 traffic and it is bridged." 

    Cheers,
Ali

On 9/1/20, 1:46 AM, "Eric Vyncke (evyncke)"  wrote:

Thank you Ali for your reply.

My comments are non-blocking anyway but I am still not too happy with 
your reply to
- section 2, I still find the text not really clear
- unsure whether I understand the reasoning on section 4.1

Else, happy with all your changes => they will improve the document

Regards

-éric

-Original Message-
From: "Ali Sajassi (sajassi)" 
Date: Tuesday, 1 September 2020 at 00:25
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , Zhaohui Zhang 

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

Hi Eric,

Thanks for your review and your comments, please refer to my 
replies inline marked with [AS].

On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker" 
 wrote:

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




--
COMMENT:

--

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs (and I 
would appreciate a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

PS: as a side note, I found that this document uses too many 
acronyms even for
short words (e.g., "SN" instead of "Subnet"). There are also 
very long
sentences that, when combined with acronyms, make reading 
difficult.

== COMMENTS ==

-- Section 2 --
About "to bridge non-IP and intra-subnet traffic and to route 
inter-subnet IP
traffic": suggest to clarify the text when the IP-VRF is IPv6 
only, then, (I
assume) that IPv4 packets will be bridged and not IP-forwarded 
(and vice-versa).

[AS] the above quoted text is provided as an example and it should 
be clear enough
Without making the sentence to verbose. 

-- Section 4.1 --
Suggest to replace "then the IRB interface MAC address MUST be 
the one used in
the initial ARP reply or ND Neighbor Advertisement (NA) for 
that TS." by "then
the IRB interface MAC address MUST be the one used in the 
initial ARP reply or
ND Neighbor Advertisement (NA) or Router Advertisement (RA) for 
that TS"
because routers MAC addresses are also advertised by Router 
Advertisements.

[AS] I don't think the IRB interface MAC address in the initial ARP 
reply can be used 
In RA because it is a multicast packet - i.e., the MAC address of 
old IRB interface and the
New IRB i

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Eric Vyncke (evyncke)]

Thank you Ali for your reply.

My comments are non-blocking anyway but I am still not too happy with your 
reply to
- section 2, I still find the text not really clear
- unsure whether I understand the reasoning on section 4.1

Else, happy with all your changes => they will improve the document

Regards

-éric

-Original Message-
From: "Ali Sajassi (sajassi)" 
Date: Tuesday, 1 September 2020 at 00:25
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , Zhaohui Zhang 

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

Hi Eric,

Thanks for your review and your comments, please refer to my replies inline 
marked with [AS].

On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker"  wrote:

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



--
COMMENT:
--

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs (and I would 
appreciate a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

PS: as a side note, I found that this document uses too many acronyms 
even for
short words (e.g., "SN" instead of "Subnet"). There are also very long
sentences that, when combined with acronyms, make reading difficult.

== COMMENTS ==

-- Section 2 --
About "to bridge non-IP and intra-subnet traffic and to route 
inter-subnet IP
traffic": suggest to clarify the text when the IP-VRF is IPv6 only, 
then, (I
assume) that IPv4 packets will be bridged and not IP-forwarded (and 
vice-versa).

[AS] the above quoted text is provided as an example and it should be clear 
enough
Without making the sentence to verbose. 

-- Section 4.1 --
Suggest to replace "then the IRB interface MAC address MUST be the one 
used in
the initial ARP reply or ND Neighbor Advertisement (NA) for that TS." 
by "then
the IRB interface MAC address MUST be the one used in the initial ARP 
reply or
ND Neighbor Advertisement (NA) or Router Advertisement (RA) for that TS"
because routers MAC addresses are also advertised by Router 
Advertisements.

[AS] I don't think the IRB interface MAC address in the initial ARP reply 
can be used 
In RA because it is a multicast packet - i.e., the MAC address of old IRB 
interface and the
New IRB interface cannot be sent in a single multicast packet.

-- Section 5.1 --
Should also mention NDP when writing "(via an ARP request)" in the first
paragraph.

[AS] Done.

In the same vein, please add "NDP cache" to "Furthermore, it adds this 
TS's MAC
and IP address association to its ARP table".

[AS] Done.

As I am not an expert in EVPN, I am puzzled by the math about the 
Length field
"either 40 (if IPv4 address is carried) or 52 (if IPv6 address is 
carried)."

[AS] for IPv6, the NLRI has 12 additional bytes.

-- Section 5.2 --
This section also only mentions IPv4 ARP table, please add IPv6 NDP 
cache.

[AS] Done.

-- Section 6.1 --
Same comments as for section 5.1

AS] Done.

-- Section 6.2 --
Same comments as for section 5.2

[AS] Done.

-- Section 7 --
Good to state "Although the language used in this section is for IPv4 
ARP, it
equally applies to IPv6 ND."; even if I would have preferred to use by 
default
IPv6 ND ;-)

[AS] yes, the quoted sentence already exist. 

Please note that in IPv6 there are often at least TWO IPv6 addresses 
per MAC
(one link-local fe80::... and one global); so, "In the following 
subsections,
it is assumed that the MAC and IP addresses of a TS have one-to-one
relationship (i.e., there is one IP address per MAC address and vice 
versa). "
is obviously never the case for IPv6. I understand that the rest of the
paragraph explains how to handle the case but it could be easier to 
treat IPv6
in a separate sentence