[bess] Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15

[Stephane Litkowski (slitkows)]

Hi Authors,

Please find below my review of the latest version of the draft:


Abstract:
The abstract refers to RFC7432bis but don’t make RFC7432bis as normative 
reference and also drafts is marked as updating RFC7432.
Here you should make a choice, either you base the draft on RFC7432 and not 
mention RFC7432bis, or base your draft on RFC7432bis, but then you should make 
it normative ref.
As a consequence, you’ll have a downref until RFC7432bis is published. I think 
this is a major issue that needs to be solved before moving fwd.


Introduction:
“EVPN-IRB enables advertising…”.
[SLI] Were you expecting to put a reference here instead of EVPN-IRB ? While 
EVPN and IRB are considered as well known, EVPN-IRB is a bit weird. But I guess 
it’s a reference to RFC9135. If yes, this must be modified. I would potentially 
right it as “EVPN IRB ([RFC9135]) enables…”. We need to have the reference 
immediately, not only at the end. Also in the document, you should choose 
between EVPN IRB and EVPN-IRB. Unfortunately, I see that RFC9135 is not 
consistent 😊 But it’s good to have consistency here.



“While a fixed 1:1 mapping between IP and MAC is a common use case that is 
addressed via existing MAC mobility procedure »
[SLI] I would add: “MAC mobility procedure, defined in [RFC7432]”

“VM move”.
[SLI] I guess you’ll need to expand VM on first use. Maybe adding a bit of 
context before would be helpful (IRB mobility scenarios in datacenter for 
instance).


“Content presented in this document is independent »
[SLI] “Content” is probably too wide IMO. I would write it as “The proposed 
solution is independent …”

“It is also largely”
[SLI] I would remove largely. Either it’s independent, or it’s not 😊

[SLI] I would personally remove the paragraphs “Content presented…” and “In 
addition to symmetric”, in favor of a slightly modified version of the last 
paragraph:
“

This document covers mobility for the following cases, independently of the 
overlay encapsulation (e.g.: MPLS, NVO 
Tunnel):¶

  *   Symmetric EVPN IRB 
overlay¶
  *   Asymmetric EVPN IRB 
overlay¶
  *   Routed EVPN 
overlay¶
“


Section 1.1:
As sections 3,4,5 are dealing with problem statement/background, wouldn’t it be 
better/more clear to group them in a big section ? You can keep your existing 
3,4,5 sections as subsections of the bigger one.

Section 2:
Please check https://www.rfc-editor.org/materials/abbrev.expansion.txt and I 
think you could remove from your list anything which is considered as well 
known. And also please check for abbrevations that require expansion on first 
use.


Section 4:
For readability purpose, I would always use the same naming conventions for the 
IP to MAC bindings, sometimes you use IP1-MAC1, sometimes IP1-M1 across the 
sections.

Section 5:
“It is possible for host to be learnt on say, PE1”
[SLI] I would just say: “It is possible for host VM route be learnt on PE1”


Section 6/7/8/9
[SLI] s/LOCAL/Local|local/g. Why using LOCAL as upper case ?

Section 7.1:
[SLI] I have a philosophical issue with the parent/child relationship you 
describe. If MAC is parent of MAC-IP, how could MAC be truly optional as a 
child cannot exist without its parent.

Section 8.1/8.2/8.4/8.5
[SLI] s/should be computed/MUST be computed/g. IMO, you cannot use “should” and 
then MUST in your bullets.

Section 8.3:
[SLI] s/is required/IS REQUIRED

Section 8.5
“If this is a SYNCed MAC-IP on a local ES, it would also result in a derived 
SYNC MAC Mx route entry”
[SLI] I find the beg of the sentence of bit weird, could you improve it ?

Section 8.6:
[SLI] Change title to “Interoperability”, same in the text of the section.
s/should be computed/MUST be computed . Why using should here and must in other 
cases, any reason ?

Section 10:
Why do you use DUPLICATE/FROZEN as upper case ? You need to make it lower case

Section 13:
You missed a “e” at the end of Patrice’s last name.

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

Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[bruno . decraene]

I support adoption : clarifying spec and improving interop is important.

Thank you for section 4 regarding Backward Compatibility.
May be 1 comment although I didn't take time to read everything in details and 
I'm not familiar with EVPN.

It's not completely clear to me whether backward compatibility MAY be preserved 
or MUST be preserved.
Unless there is a good technical reason, my preference would be for "MUST be 
preserved".
e.g.
§4

OLD: Backward compatibility with implementations doing the bitwise
   logical-OR operation can be preserved by the advertisement of SIDs


NEW: Backward compatibility with implementations doing the bitwise

   logical-OR operation is preserved thanks to the advertisement of SIDs

§3.1
OLD:

it is

   REQUIRED that proper LBL, LNL, and FL values be set corresponding to

   the supported SID Structure for the End.DT2M SRv6 Service SIDs.


Given that this is already the second spec to clarify this, may be "proper [..] 
value" could be expanded so as to specify the precise behavior which is 
REQUIRED.


Probably similar comment for §3.2 ("The LBL, LNL, and FL MUST be set to 
appropriate values").

Thanks,
Regards,
--Bruno



Orange Restricted
From: BESS  On Behalf Of Matthew Bocci (Nokia)
Sent: Thursday, September 28, 2023 4:49 PM
To: bess@ietf.org
Cc: draft-trr-bess-bgp-srv6-a...@ietf.org
Subject: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

This email begins a two-week WG adoption and IPR poll for 
draft-trr-bess-bgp-srv6-args-02 [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.
Currently, there is currently no IPR disclosure against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond to the IPR poll only if you are aware of any IPR that has not yet been 
disclosed in conformance with IETF rules.

This poll for adoption closes on Thursday 12th October 2023.

[1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP Services 
(ietf.org)

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Mankamana Mishra (mankamis)]

Support the adoption.

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, October 5, 2023 at 3:46 AM
To: bess@ietf.org 
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 

Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16
WG

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

Please review the draft and post any comments to the BESS mailing list.

This poll will close on Thursday 12th October.

Regards

Matthew

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network 
providers.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] I-D Action: draft-ietf-bess-evpn-irb-extended-mobility-16.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-evpn-irb-extended-mobility-16.txt is now
available. It is a work item of the BGP Enabled ServiceS (BESS) WG of the
IETF.

   Title:   Extended Mobility Procedures for EVPN-IRB
   Authors: Neeraj Malhotra
Ali Sajassi
Aparna Pattekar
Jorge Rabadan
Avinash Lingala
John Drake
   Name:draft-ietf-bess-evpn-irb-extended-mobility-16.txt
   Pages:   26
   Dates:   2023-10-11

Abstract:

   The procedure to handle host mobility in a layer 2 Network with EVPN
   control plane is defined as part of [RFC7432].  EVPN has since
   evolved to find wider applicability across various IRB use cases that
   include distributing both MAC and IP reachability via a common EVPN
   control plane.  MAC Mobility procedures defined in [RFC7432] are
   extensible to IRB use cases if a fixed 1:1 mapping between host IP
   and MAC is assumed across host moves.  Generic mobility support for
   IP and MAC addresses that allows these bindings to change across
   moves IS REQUIRED to support a broader set of EVPN IRB use cases.
   EVPN all-active multi-homing further introduces scenarios that
   require additional consideration from mobility perspective.  This
   document enumerates a set of design considerations applicable to
   mobility across these EVPN IRB use cases and updates sequence number
   assignment procedures defined in [RFC7432] to address these IRB use
   cases.

   NOTE TO IESG (TO BE DELETED BEFORE PUBLISHING): This draft lists six
   authors which is above the required limit of five.  Given significant
   and active contributions to the draft from all six authors over the
   course of six years, we would like to request IESG to allow
   publication with six authors.  Specifically, the three Cisco authors
   are the original inventors of these procedures and contributed
   heavily to rev 0 draft, most of which is still intact.  AT&T is also
   a key contributor towards defining the use cases that this document
   addresses as well as the proposed solution.  Authors from Nokia and
   Juniper have further contributed to revisions and discussions
   steadily over last six years to enable respective implementations and
   a wider adoption.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-16

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-irb-extended-mobility-16

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [bess] Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15

[Neeraj Malhotra (nmalhotr)]

Hi Stephane,

Many thanks for the detailed review and comments. Have updated the document 
addressing all of the comments below.

Specifically regarding the issue of referencing rfc7432 or rfc7432bis, I have 
modified the reference to be on rfc7432 since existing 7432 is sufficient as a 
reference for all procedures covered in this document and it alleviates 
unnecessary dependency on publication of 7432bis.

Thanks,
Neeraj

From: Stephane Litkowski (slitkows) 
Date: Wednesday, October 11, 2023 at 6:14 AM
To: draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org 
, bess@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15
Hi Authors,

Please find below my review of the latest version of the draft:


Abstract:
The abstract refers to RFC7432bis but don’t make RFC7432bis as normative 
reference and also drafts is marked as updating RFC7432.
Here you should make a choice, either you base the draft on RFC7432 and not 
mention RFC7432bis, or base your draft on RFC7432bis, but then you should make 
it normative ref.
As a consequence, you’ll have a downref until RFC7432bis is published. I think 
this is a major issue that needs to be solved before moving fwd.


Introduction:
“EVPN-IRB enables advertising…”.
[SLI] Were you expecting to put a reference here instead of EVPN-IRB ? While 
EVPN and IRB are considered as well known, EVPN-IRB is a bit weird. But I guess 
it’s a reference to RFC9135. If yes, this must be modified. I would potentially 
right it as “EVPN IRB ([RFC9135]) enables…”. We need to have the reference 
immediately, not only at the end. Also in the document, you should choose 
between EVPN IRB and EVPN-IRB. Unfortunately, I see that RFC9135 is not 
consistent 😊 But it’s good to have consistency here.



“While a fixed 1:1 mapping between IP and MAC is a common use case that is 
addressed via existing MAC mobility procedure »
[SLI] I would add: “MAC mobility procedure, defined in [RFC7432]”

“VM move”.
[SLI] I guess you’ll need to expand VM on first use. Maybe adding a bit of 
context before would be helpful (IRB mobility scenarios in datacenter for 
instance).


“Content presented in this document is independent »
[SLI] “Content” is probably too wide IMO. I would write it as “The proposed 
solution is independent …”

“It is also largely”
[SLI] I would remove largely. Either it’s independent, or it’s not 😊

[SLI] I would personally remove the paragraphs “Content presented…” and “In 
addition to symmetric”, in favor of a slightly modified version of the last 
paragraph:
“

This document covers mobility for the following cases, independently of the 
overlay encapsulation (e.g.: MPLS, NVO 
Tunnel):¶

  *   Symmetric EVPN IRB 
overlay¶
  *   Asymmetric EVPN IRB 
overlay¶
  *   Routed EVPN 
overlay¶
“


Section 1.1:
As sections 3,4,5 are dealing with problem statement/background, wouldn’t it be 
better/more clear to group them in a big section ? You can keep your existing 
3,4,5 sections as subsections of the bigger one.

Section 2:
Please check https://www.rfc-editor.org/materials/abbrev.expansion.txt and I 
think you could remove from your list anything which is considered as well 
known. And also please check for abbrevations that require expansion on first 
use.


Section 4:
For readability purpose, I would always use the same naming conventions for the 
IP to MAC bindings, sometimes you use IP1-MAC1, sometimes IP1-M1 across the 
sections.

Section 5:
“It is possible for host to be learnt on say, PE1”
[SLI] I would just say: “It is possible for host VM route be learnt on PE1”


Section 6/7/8/9
[SLI] s/LOCAL/Local|local/g. Why using LOCAL as upper case ?

Section 7.1:
[SLI] I have a philosophical issue with the parent/child relationship you 
describe. If MAC is parent of MAC-IP, how could MAC be truly optional as a 
child cannot exist without its parent.

Section 8.1/8.2/8.4/8.5
[SLI] s/should be computed/MUST be computed/g. IMO, you cannot use “should” and 
then MUST in your bullets.

Section 8.3:
[SLI] s/is required/IS REQUIRED

Section 8.5
“If this is a SYNCed MAC-IP on a local ES, it would also result in a derived 
SYNC MAC Mx route entry”
[SLI] I find the beg of the sentence of bit weird, could you improve it ?

Section 8.6:
[SLI] Change title to “Interoperability”, same in the text of the section.
s/should be computed/MUST be computed . Why using should here and must in other 
cases, any reason ?

Section 10:
Why do you use DUPLICATE/FROZEN as upper case ? You need to make it lower case

Section 13:
You missed a “e” at the end of Patrice’s last name.

___

[bess] I-D Action: draft-skr-bess-evpn-pim-proxy-02.txt

[internet-drafts]

Internet-Draft draft-skr-bess-evpn-pim-proxy-02.txt is now available. It is a
work item of the BGP Enabled ServiceS (BESS) WG of the IETF.

   Title:   PIM Proxy in EVPN Networks
   Authors: Jorge Rabadan
Jayant Kotalwar
Senthil Sathappan
Zhaohui Zhang
Ali Sajassi
Mankamana Mishra
   Name:draft-skr-bess-evpn-pim-proxy-02.txt
   Pages:   25
   Dates:   2023-10-11

Abstract:

   Ethernet Virtual Private Networks are becoming prevalent in Data
   Centers, Data Center Interconnect (DCI) and Service Provider VPN
   applications.  One of the goals that EVPN pursues is the reduction of
   flooding and the efficiency of CE-based control plane procedures in
   Broadcast Domains.  Examples of this are Proxy ARP/ND and IGMP/MLD
   Proxy.  This document complements the latter, describing the
   procedures required to minimize the flooding of PIM messages in EVPN
   Broadcast Domains, and optimize the IP Multicast delivery between PIM
   routers.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-skr-bess-evpn-pim-proxy/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-skr-bess-evpn-pim-proxy-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-skr-bess-evpn-pim-proxy-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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