Re: [bess] Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

[Jeffrey (Zhaohui) Zhang]

Hi Jorge,

Thanks for the revision.
Please see zzh> below for two comments.



Juniper Business Use Only
From: Jorge Rabadan (Nokia) 
Sent: Monday, October 23, 2023 10:33 AM
To: Jeffrey (Zhaohui) Zhang ; Kiran Nagaraj (Nokia) 
; Wen Lin ; 'Ali Sajassi (sajassi)' 

Cc: 'BESS' 
Subject: Re: Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

[External Email. Be cautious of content]

Hi Jeffrey,

Thanks very much for the review. Version 6 is published addressing your 
comments.

Please see in-line.

Thanks!
Jorge



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Date: Wednesday, September 27, 2023 at 5:34 PM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, Kiran Nagaraj 
(Nokia) mailto:kiran.naga...@nokia.com>>, Wen Lin 
mailto:w...@juniper.net>>, 'Ali Sajassi (sajassi)' 
mailto:saja...@cisco.com>>
Cc: 'BESS' mailto:bess@ietf.org>>
Subject: Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

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.



Hi,

I have the following comments/suggestions/questions:

Idnits reported:

  -- The draft header indicates that this document updates RFC8365, but the
 abstract doesn't seem to mention this, which it should.
[Jorge] good point. Added.


Would this update 7432 as well?
[Jorge] since 7432bis obsoletes 7432 and refers to this document, it is 
probably ok not to say it updates 7432... but I don't have a strong opinion. It 
may depend on how fast 7432bis progresses as well?

Zzh> 7432bis WGLC has not happened yet, so I believe this one will go before 
7432bis and should update 7432.


  == Outdated reference: A later version (-06) exists of
 draft-ietf-bess-evpn-geneve-05

I normally don't reference a specific revision of a document, unless the 
revision number matters. If you remove the revision in the reference, you'll 
not need to worry about updating it again.
[Jorge] sure, done.


Given that this is ahead of rfc7432bis, the "EVPN ESI Multihoming Attributes" 
registry creation for the 1-octet Flags field in the ESI Label Extended 
Community should be moved to this draft.
[Jorge] As long as this document it is really ahead of 7432bis, sure. We added 
it to the IANA section, and we can always remove it if 7432bis goes out before 
this one.

Zzh> I should have noticed it earlier, but now I think the name "EVPN ESI 
Multihoming Attributes" is a bit confusing. I think it's better called "EVPN 
ESI Label Extended Community Flags" registry. In addition, all existing bits 
should also be documented in the registry-creation request.
Zzh> Thanks!
Zzh> Jeffrey


"MPLS-based IP Tunnel" does not seem to be accurate to me. It should be 
"IP-based MPLS Tunnel". Related to that, the three tunnel types can be renamed 
to:

- IP-based MPLS Tunnel
- (SR-)MPLS Tunnel
- IP Tunnel

I don't think we need "group" in terms like "group MPLS-based IP" - it can 
simply be "IP-based MPLS".
[Jorge] ok, changed


There a few references like the following:

   [RFC9012] BGP Encapsulation extended community

I believe the reference should be put after the relevant text:

   BGP Encapsulation extended community [RFC9012]
[Jorge] ok, fixed.



Thanks.
Jeffrey

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

[bess] WG adoption request: BGP MPLS Namespaces

[Kaliraj Vairavakkalai]

Hi Chairs,

I’d like to request WG adoption for the following draft:

https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/

I have presented it in IETF-111, IETF-117, and had requested WG adoption at the 
mic in IETF-117.

Could you please put my request in the queue?

Thanks,
Kaliraj


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

[bess] I-D Action: draft-ietf-bess-evpn-mvpn-seamless-interop-06.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-evpn-mvpn-seamless-interop-06.txt is now
available. It is a work item of the BGP Enabled ServiceS (BESS) WG of the
IETF.

   Title:   Seamless Multicast Interoperability between EVPN and MVPN PEs
   Authors: Ali Sajassi
Kesavan Thiruvenkatasamy
Samir Thoria
Ashutosh Gupta
Luay Jalil
   Name:draft-ietf-bess-evpn-mvpn-seamless-interop-06.txt
   Pages:   38
   Dates:   2023-10-23

Abstract:

   Ethernet Virtual Private Network (EVPN) solution is becoming
   pervasive for Network Virtualization Overlay (NVO) services in data
   center (DC) and Enterprise networks as well as the next generation
   VPN services in service provider (SP) networks.

   As service providers transform their networks in their Central
   Offices (COs) towards the next generation data center with Software
   Defined Networking (SDN) based fabric and Network Function
   Virtualization (NFV), they want to be able to maintain their offered
   services including Multicast VPN (MVPN) service between their
   existing network and their new Service Provider Data Center (SPDC)
   network seamlessly without the use of gateway devices.  They want to
   have such seamless interoperability between their new SPDCs and their
   existing networks for a) reducing cost, b) having optimum forwarding,
   and c) reducing provisioning.  This document describes a unified
   solution based on RFCs 6513 & 6514 for seamless interoperability of
   Multicast VPN between EVPN and MVPN PEs.  Furthermore, it describes
   how the proposed solution can be used as a routed multicast solution
   in data centers with only EVPN PEs.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mvpn-seamless-interop/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mvpn-seamless-interop-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-mvpn-seamless-interop-06

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] Genart early review of draft-ietf-bess-evpn-ac-aware-bundling-03

[Mankamana Mishra (mankamis)]

Thanks for your comment, will be pushing updated version as soon as window 
opens during IETF.

From: Russ Housley via Datatracker 
Date: Friday, October 20, 2023 at 9:02 AM
To: gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: Genart early review of draft-ietf-bess-evpn-ac-aware-bundling-03
Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-bess-evpn-ac-aware-bundling-03
Reviewer: Russ Housley
Review Date: 2023-10-20
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

Section 8: Please clearly identify the IANA registry.


Minor Concerns:

General: Several places, the document includes reference of the form
"[RFC7432] section x.y.z".  It would be much more clear to use the form
"Section x.y.z of [RFC7432]".

Section 6.1 has "attachment circuit ID Extended Community" below the
figure.  Is this a caption?  If so, please center the caption and add a
figure number.


Nits:

General: s/draft/document/ (prepare for publication as an RFC)

Abstract: s/EVPN (Ethernet VPNs) provides/An EVPN (Ethernet VPN) provides/

Section 1: s/This draft proposes/This document specifies/

Section 1.1: s/MAC-2 it can not determine which AC this MAC belongs to/
  /MAC-2, it can not determine the AC associated with this MAC/

Section 1.2: s/which subnet this IGMP membership request belong to/
  /which subnet this IGMP membership request belongs/

Section 1.2: s/forearded to/forwarded to/

Section 3: s/multiple VLAN are configured on/multiple VLAN are configured/

Section 3: s/defined in [RFC7432]/defined in [RFC7432]./

Section 4.1.1.2: s/non multihome/non-multihomed/

Section 4.1.1.2: s/defined in [RFC7432]/defined in [RFC7432]./

Section 4.2.1: s/section 13.1/Section 13.1./

Section 4.2.2: s/in [RFC7432]/in [RFC7432]./

Section 5: s/In this case/In this case,/

Section 6.2: s/is faily large/is fairly large/

Section 6.2: s/This approach is complexifying/This approach adds complexity to/

Section 6.2: s/There is drawback/There is a drawback/


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

Re: [bess] Genart early review of draft-ietf-bess-bgp-multicast-05

[Jeffrey (Zhaohui) Zhang]

Hi Joel,

Thanks for your review and comments.
I will address them and come back.

Jeffrey


Juniper Business Use Only
-Original Message-
From: Joel Halpern via Datatracker 
Sent: Monday, October 23, 2023 3:00 PM
To: gen-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org
Subject: Genart early review of draft-ietf-bess-bgp-multicast-05

[External Email. Be cautious of content]


Reviewer: Joel Halpern
Review result: Not Ready

This is a requested genart early review of

draft-ietf-bess-bgp-multicast-05

Prepared on 23-Oct-2023

Summary: This draft is not ready, having a number of issues that need to be 
addressed.

I presume this draft will be socialized with the PIM and IDR working groups 
before completion (or maybe it already has been?)

Major:
While I appreciate the effort to give an overview of the operation before
providing the specification, the actual text is almost impossible to
follow.   At a guess, the authors have a coherent view of what happens, and
have then written down each "interesting" piece.   This does not give the
reader clarity. As a first step, before giving the overview, all the
terminology needs to be defined.  Including such things as the fact that
MCAST-TREE NLRI is a general holder, within which there are a number of
different NLRI (which is finally explained in section 2, after the reader
is thoroughly confused.)  All terms and abbreviations should be defined or,
when they are from other documents, expanded with a citation so the reader
knows where to look for the term.  (I did figure out what FHR and LHR were,
but the draft did not help me do so.) Secondly, the extensive use of
construction of the form ~this use of construct A is just like the use in
document B except...~ is very confusing.  The reader is left without a
coherent description of how this protocol works, exactly which pieces from
the other document must be followed, and exactly how the changes are to be
applied. Third, if the intention of the introductory material is to provide
a perspective on, but not duplicative specification of, the material in
section 2.2, then each overview should have forward references explaining
where the detailed procedures can be found.  If material in the overview is
intended to be the normative specification of the operation (as for example
when and which rotue communities are to be used, and apparently all of
section 1.2.1.1) then normative language is needed.  It is quite hard to
exgtract from these sections the required procedures.

I also note that ID-Nits ha a lot of complaints.  I will not repeat them,
but they need to be dealt with. (For example, the addresses used in various
examples are not example addresses.  They should be.)

Scaling needs to be better addressed.  While I understand the use of RT
constraints helps the avoidance of overloading the leaves of the tree, it
appears that any network using route reflectors is likely to have state
about every sender of every multicast group in every rotue reflector.  It
may be that this is acceptable.  But it should be called out explicitly.

Section 2.2.1 sates that source advertisement will be triggered only by sources 
sending multicast traffic.  And will expire based on time.  Except that the 
network has no idea what the suitable time interval is for a given multicast 
group.  Some groups will have long inter-packet intervals, while some will be 
short and some will be quite variable.  Also, some groups will have the 
property that the senders will know who they are before sending, and receivers 
may even want to join before the senders are active.  If the working group 
wishes to exclude such use cases, then the document should be explicit about 
what use cases it is covering.

Moderate:
Additional explanation is needed in section 1.2.1.2.  This section describes 
how to set up a shared tree for an ANY-Source Multicast Group.  Unlike the 
earlier discussion of advertising sources with a route target community to 
restrict distribution, this section explicitly says that the sources sending to 
the ASM Group are advertised in BGP without the restricting community.  I 
presume there is some other assumed aspect that restrits the information so it 
is only received by the Rendezvous points for the shared tree.  But I can not 
see how this is achieved.  Please add explanation of why this approach does not 
flood the whole domain with information it does not want or need.

The last paragraph (short) of section 1.2.1.2 gives a vague description of 
certain cases.  Presuming it is described in more detail later, a forward 
reference would be extremely helpful.

Section 1.2.1.3 has very confusing use of ingress and egress PE.  I would have 
assumed ingress and egress were in terms of the direction of traffic flow (from 
traffic sources to interested receivers).  But the usage i

[bess] Genart early review of draft-ietf-bess-bgp-multicast-05

[Joel Halpern via Datatracker]

Reviewer: Joel Halpern
Review result: Not Ready

This is a requested genart early review of

draft-ietf-bess-bgp-multicast-05

Prepared on 23-Oct-2023

Summary: This draft is not ready, having a number of issues that need to be
addressed.

I presume this draft will be socialized with the PIM and IDR working groups
before completion (or maybe it already has been?)

Major:
While I appreciate the effort to give an overview of the operation before
providing the specification, the actual text is almost impossible to
follow.   At a guess, the authors have a coherent view of what happens, and
have then written down each "interesting" piece.   This does not give the
reader clarity. As a first step, before giving the overview, all the
terminology needs to be defined.  Including such things as the fact that
MCAST-TREE NLRI is a general holder, within which there are a number of
different NLRI (which is finally explained in section 2, after the reader
is thoroughly confused.)  All terms and abbreviations should be defined or,
when they are from other documents, expanded with a citation so the reader
knows where to look for the term.  (I did figure out what FHR and LHR were,
but the draft did not help me do so.) Secondly, the extensive use of
construction of the form ~this use of construct A is just like the use in
document B except...~ is very confusing.  The reader is left without a
coherent description of how this protocol works, exactly which pieces from
the other document must be followed, and exactly how the changes are to be
applied. Third, if the intention of the introductory material is to provide
a perspective on, but not duplicative specification of, the material in
section 2.2, then each overview should have forward references explaining
where the detailed procedures can be found.  If material in the overview is
intended to be the normative specification of the operation (as for example
when and which rotue communities are to be used, and apparently all of
section 1.2.1.1) then normative language is needed.  It is quite hard to
exgtract from these sections the required procedures.

I also note that ID-Nits ha a lot of complaints.  I will not repeat them,
but they need to be dealt with. (For example, the addresses used in various
examples are not example addresses.  They should be.)

Scaling needs to be better addressed.  While I understand the use of RT
constraints helps the avoidance of overloading the leaves of the tree, it
appears that any network using route reflectors is likely to have state
about every sender of every multicast group in every rotue reflector.  It
may be that this is acceptable.  But it should be called out explicitly.

Section 2.2.1 sates that source advertisement will be triggered only by sources
sending multicast traffic.  And will expire based on time.  Except that the
network has no idea what the suitable time interval is for a given multicast
group.  Some groups will have long inter-packet intervals, while some will be
short and some will be quite variable.  Also, some groups will have the
property that the senders will know who they are before sending, and receivers
may even want to join before the senders are active.  If the working group
wishes to exclude such use cases, then the document should be explicit about
what use cases it is covering.

Moderate:
Additional explanation is needed in section 1.2.1.2.  This section describes
how to set up a shared tree for an ANY-Source Multicast Group.  Unlike the
earlier discussion of advertising sources with a route target community to
restrict distribution, this section explicitly says that the sources sending to
the ASM Group are advertised in BGP without the restricting community.  I
presume there is some other assumed aspect that restrits the information so it
is only received by the Rendezvous points for the shared tree.  But I can not
see how this is achieved.  Please add explanation of why this approach does not
flood the whole domain with information it does not want or need.

The last paragraph (short) of section 1.2.1.2 gives a vague description of
certain cases.  Presuming it is described in more detail later, a forward
reference would be extremely helpful.

Section 1.2.1.3 has very confusing use of ingress and egress PE.  I would have
assumed ingress and egress were in terms of the direction of traffic flow (from
traffic sources to interested receivers).  But the usage in both paragraphs
seems to be exactly the opposite.

Section 1.2.3 refers to establishing information via an IGP ("IGP neighbor
discovery").  Except that the earlier descriptions indicate that the deployment
case here is for a pure BGP domain, with no IGP.  (Otherwise, there would need
to be extensive procedures as to how the multicasts traverse regions that use
the IGP instead of BGP.)

Section 1.2.4 discusses handling when multip

Re: [bess] Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

[Jorge Rabadan (Nokia)]

Hi Jeffrey,

Thanks very much for the review. Version 6 is published addressing your 
comments.

Please see in-line.

Thanks!
Jorge

From: Jeffrey (Zhaohui) Zhang 
Date: Wednesday, September 27, 2023 at 5:34 PM
To: Jorge Rabadan (Nokia) , Kiran Nagaraj (Nokia) 
, Wen Lin , 'Ali Sajassi (sajassi)' 

Cc: 'BESS' 
Subject: Shepherd review of draft-ietf-bess-evpn-mh-split-horizon-05

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.



Hi,

I have the following comments/suggestions/questions:

Idnits reported:

  -- The draft header indicates that this document updates RFC8365, but the
 abstract doesn't seem to mention this, which it should.
[Jorge] good point. Added.


Would this update 7432 as well?
[Jorge] since 7432bis obsoletes 7432 and refers to this document, it is 
probably ok not to say it updates 7432… but I don’t have a strong opinion. It 
may depend on how fast 7432bis progresses as well?


  == Outdated reference: A later version (-06) exists of
 draft-ietf-bess-evpn-geneve-05

I normally don't reference a specific revision of a document, unless the 
revision number matters. If you remove the revision in the reference, you'll 
not need to worry about updating it again.
[Jorge] sure, done.


Given that this is ahead of rfc7432bis, the "EVPN ESI Multihoming Attributes" 
registry creation for the 1-octet Flags field in the ESI Label Extended 
Community should be moved to this draft.
[Jorge] As long as this document it is really ahead of 7432bis, sure. We added 
it to the IANA section, and we can always remove it if 7432bis goes out before 
this one.


"MPLS-based IP Tunnel" does not seem to be accurate to me. It should be 
"IP-based MPLS Tunnel". Related to that, the three tunnel types can be renamed 
to:

- IP-based MPLS Tunnel
- (SR-)MPLS Tunnel
- IP Tunnel

I don't think we need "group" in terms like "group MPLS-based IP" - it can 
simply be "IP-based MPLS".
[Jorge] ok, changed


There a few references like the following:

   [RFC9012] BGP Encapsulation extended community

I believe the reference should be put after the relevant text:

   BGP Encapsulation extended community [RFC9012]
[Jorge] ok, fixed.



Thanks.
Jeffrey

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

[bess] I-D Action: draft-ietf-bess-evpn-mh-split-horizon-06.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-evpn-mh-split-horizon-06.txt is now available.
It is a work item of the BGP Enabled ServiceS (BESS) WG of the IETF.

   Title:   EVPN Multi-Homing Extensions for Split Horizon Filtering
   Authors: Jorge Rabadan
Kiran Nagaraj
Wen Lin
Ali Sajassi
   Name:draft-ietf-bess-evpn-mh-split-horizon-06.txt
   Pages:   18
   Dates:   2023-10-23

Abstract:

   Ethernet Virtual Private Network (EVPN) is commonly used along with
   Network Virtualization Overlay (NVO) tunnels, as well as MPLS and
   Segment Routing tunnels.  The EVPN multi-homing procedures may be
   different depending on the tunnel type used in the EVPN Broadcast
   Domain.  In particular, there are two multi-homing Split Horizon
   procedures to avoid looped frames on the multi-homed CE: ESI Label
   based and Local Bias.  ESI Label based Split Horizon is used for
   MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for other
   tunnels, E.g., VXLAN tunnels.  The existing specifications do not
   allow the operator to decide which Split Horizon procedure to use for
   tunnel encapsulations that could support both.  Examples of tunnels
   that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or
   SRv6.  This document updates the EVPN Multi-Homing procedures in
   RFC8365 so that an operator can decide the Split Horizon procedure
   for a given tunnel depending on their own requirements.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-split-horizon-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-mh-split-horizon-06

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] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Jorge and all,
Lots of thanks for a prompt and very encouraging response!

I have looked up the -09 revision, and the new text looks OK.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, October 23, 2023 4:03 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

Thanks once more for reviewing. Since the WG adoption call will start soon, we 
published version 9 to address your comments.

For points 1..3, we modified the text to make as per your comments.
For point 4, we clarified that the two bullets are both true for the primary PE.

Thanks,
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, October 22, 2023 at 8:44 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

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.


Jorge,
Lots of thanks for the update.

A few comments on the new text of Section 3.1:


1.   “The Ethernet Tag should be set to 0” - IMHO this is MUST or, at least 
SHOULD. The IP-VRF that installs this route cannot interpret a non-zero value 
of the Ethernet Tag in any way.

2.   “The route MUST carry the Route Target of the corresponding IP-VRF” - 
IMHO it should be “all Export Route Targets of the corresponding IP VRF” (there 
may be more than one Export Route Target in an IP-VRF, and an IP-VRF may use a 
different set of Import Route Targets.

3.   “For backup path, the Primary PE will advertise P=1 and the Backup PE 
will advertise P=0, B=1”:

a.   This seems to apply to Single-Active multi-homing only, because the 
previous sentence covers All-Active multi-homing

b.   Should be “the Primary PE will advertise P=1 and B=0”

4.   “The Primary PE SHOULD be a PE with a routing adjacency to the 
attached CE” and “The Primary PE MAY be … elected by a DF Election” - IMHO and 
FWIW with Single-Active multi-homing (which is the context for discussing 
Primary/Backup roles) these two statements always elect the same PE, i.e., one 
of these statements can be removed.
Hopefully, these notes will be useful.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Friday, October 20, 2023 9:57 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: bess@ietf.org; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

We just published version 08.
We made some changes in section 3.1 based on your comments.

Note that the draft does not really create a new situation for the AD per EVI 
route in which it could be imported in different VRF types. Prior to this 
document the A-D per EVI route could also be imported in a MAC-VRF or a VPWS 
type of service.

Thanks!
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Thursday, July 13, 2023 at 2:25 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

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.


Jorge,
Again, lots of thanks for your response.

I have doubts regarding your statement “the IP A-D per EVI route carries the 
BGP encapsulation extended community” in the context of pure EVPN-MPLS.

1.   My reading of Section 5.3.1 of RFC 
8365, nodes that 
support only MPLS encapsulation are not required to add this Extended Community 
to any EVPN routes, and the nodes that receive EVPN routes without this 
Extended Community attached assume MPLS encapsulation

2.   Section 4.4.1 of RFC 9136 also does not require adding this Extended 
Community to EVPN IP Prefix routes, only mentions that it (as well as the 
Router’s MAC Extended Community) “may be added”

3.   Last but not least, Encapsulation Extended community is not mentioned 
at all in Section 3.1 of the 
draft
 that defines construction of IP per-EVI  A-D r

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

[Jorge Rabadan (Nokia)]

Thank you Éric.
I understand your point. My point is that this spec is really not introducing 
any new side effect related to scale of MACs changing/moving.

We appreciate your time and help!
Thx
Jorge

From: Eric Vyncke (evyncke) 
Date: Monday, October 23, 2023 at 6:08 AM
To: Jorge Rabadan (Nokia) , 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)

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.


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-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] Question and comments on the EVPN IP Aliasing draft

[Jorge Rabadan (Nokia)]

Hi Sasha,

Thanks once more for reviewing. Since the WG adoption call will start soon, we 
published version 9 to address your comments.

For points 1..3, we modified the text to make as per your comments.
For point 4, we clarified that the two bullets are both true for the primary PE.

Thanks,
Jorge

From: Alexander Vainshtein 
Date: Sunday, October 22, 2023 at 8:44 AM
To: Jorge Rabadan (Nokia) 
Cc: bess@ietf.org , 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org 

Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

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.


Jorge,
Lots of thanks for the update.

A few comments on the new text of Section 3.1:


1.   “The Ethernet Tag should be set to 0” – IMHO this is MUST or, at least 
SHOULD. The IP-VRF that installs this route cannot interpret a non-zero value 
of the Ethernet Tag in any way.

2.   “The route MUST carry the Route Target of the corresponding IP-VRF” – 
IMHO it should be “all Export Route Targets of the corresponding IP VRF” (there 
may be more than one Export Route Target in an IP-VRF, and an IP-VRF may use a 
different set of Import Route Targets.

3.   “For backup path, the Primary PE will advertise P=1 and the Backup PE 
will advertise P=0, B=1”:

a.   This seems to apply to Single-Active multi-homing only, because the 
previous sentence covers All-Active multi-homing

b.   Should be “the Primary PE will advertise P=1 and B=0”

4.   “The Primary PE SHOULD be a PE with a routing adjacency to the 
attached CE” and “The Primary PE MAY be … elected by a DF Election” – IMHO and 
FWIW with Single-Active multi-homing (which is the context for discussing 
Primary/Backup roles) these two statements always elect the same PE, i.e., one 
of these statements can be removed.
Hopefully, these notes will be useful.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Friday, October 20, 2023 9:57 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

We just published version 08.
We made some changes in section 3.1 based on your comments.

Note that the draft does not really create a new situation for the AD per EVI 
route in which it could be imported in different VRF types. Prior to this 
document the A-D per EVI route could also be imported in a MAC-VRF or a VPWS 
type of service.

Thanks!
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Thursday, July 13, 2023 at 2:25 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

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.


Jorge,
Again, lots of thanks for your response.

I have doubts regarding your statement “the IP A-D per EVI route carries the 
BGP encapsulation extended community” in the context of pure EVPN-MPLS.

1.   My reading of Section 5.3.1 of RFC 
8365, nodes that 
support only MPLS encapsulation are not required to add this Extended Community 
to any EVPN routes, and the nodes that receive EVPN routes without this 
Extended Community attached assume MPLS encapsulation

2.   Section 4.4.1 of RFC 9136 also does not require adding this Extended 
Community to EVPN IP Prefix routes, only mentions that it (as well as the 
Router’s MAC Extended Community) “may be added”

3.   Last but not least, Encapsulation Extended community is not mentioned 
at all in Section 3.1 of the 
draft
 that defines construction of IP per-EVI  A-D routes.
With regard to your statement “we never specified how to import routes with a 
single label if they come with multiple route targets and they match different 
MAC-VRFs and IP-VRFs” : I agree that this has never been specified, but, IMHO, 
this was not really needed, because, until now, the standards defining these 
routes have never allowed any alternatives. From my POV the draft creates a new 
situation, where, locking just at the NLRI of the EVPN Type 1 route, it is 
impossible to decide whether it will be installed in the FDB of a MAC-VRF/BD, 
or in the RIB (and FIB) of an IP-VRF.
So I think some text in the draft clarifying this would be most useful.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Tuesday, July 11, 2023 9:06 PM
To: Alexan

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

[Jorge Rabadan (Nokia)]

Hi Murray,

Thanks very much for reviewing.

We cleaned the glossary in version 9.
The document deals with an optimization of the customer MAC flush mechanisms in 
RFC7623, but if your implementation cannot enable this optimization, 
interoperability is still ok given that the procedures in RFC7623 are still 
enforced. The changes in version 9 should make this clearer.

Thanks!
Jorge


From: Murray Kucherawy via Datatracker 
Date: Wednesday, August 9, 2023 at 11:17 PM
To: The IESG 
Cc: draft-ietf-bess-pbb-evpn-isid-cmacfl...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci (Nokia) 

Subject: Murray Kucherawy'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.



Murray Kucherawy 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:
--

The term "B-Component" is in the glossary, but isn't used in this document.
Same with "CE" and "vES".

I find the use of SHOULD around an administrative option to be peculiar.  This
is normally associated with interoperability requirements, but even setting
that aside, let's say I decide to implement this in a way that the solution
overall or the capability defined in Section 4 simply can't be enabled or
disabled.  Is the implementation still viable?  I also concur with John's point
that the SHOULD-MAY combination is similarly strange.


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

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

[Jorge Rabadan (Nokia)]

Hi Warren,

Thanks very much for reviewing.
Version 9 addresses Éric’s and Pascal’s comments.
This is a small extension of the procedures in RFC7623, but we acknowledge that 
it is not easy to grasp the benefits unless you are familiar with RFC7623.
To that effect, in version 9, we added a sentence in the introduction section 
saying:

“This specification assumes that the reader is familiar with the procedures in 
RFC7623”

Thanks.
Jorge

From: Warren Kumari via Datatracker 
Date: Wednesday, August 9, 2023 at 1:58 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) , 
pthub...@cisco.com , int-...@ietf.org 
Subject: Warren Kumari'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.



Warren Kumari has entered the following ballot position for
draft-ietf-bess-pbb-evpn-isid-cmacflush-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/



--
COMMENT:
--

I fully agree with Eric's "This is a very specific area of work and the text is
not easy to read for a non expert. I read it, but was somewhat baffled by the
quantity of acronyms and terminology, and to I too relied on Pascal Thubert's
IntDir review
(https://datatracker.ietf.org/doc/review-ietf-bess-pbb-evpn-isid-cmacflush-08-intdir-telechat-thubert-2023-08-07/)
to help choose my position.


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

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

[Jorge Rabadan (Nokia)]

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] Intdir telechat review of draft-ietf-bess-pbb-evpn-isid-cmacflush-08

[Jorge Rabadan (Nokia)]

Hi Pascal,

Thank you very much for reviewing.
Your comments are addressed in version 09.
Some responses to your comments below:

Please indicate how the CE can know if the PW failure is not due to the PE
failure, in which case extending the Customer MAC flush solution in RFC7623
seems more efficient as all I-SIDs with link / PW starting there are affected.
And how the double flush in avoided in the case of a non-null ESI with this
spec on as well.

[Jorge] we improved the introduction, hopefully it clarifies those points now.

I found this
"
When I-SID-based C-MAC-flush is disabled, the PE will follow the [RFC7623]
procedures for C-MAC-flush. " but it does not answer either of the above. e.g.,
does the reciprocal of the above apply too? or can they be both on?

[Jorge] good point. We replaced the sentence with:
>The PE MUST follow the RFC7623 procedures for C-MAC-flush. This specification 
>brings some additional procedures when I-SID-based C-MAC-flush is enabled.

I'd have thought that upon loss of connectivity with PE3, CE3 enables the PW to[
PE4 and tells PE4 to send the update. Now it seems that the main player of this
spec is actually PE4 and that it's death is reported some other way. If that's
correct, saying it earlier would have saved me a headache ;)

[Jorge] hopefully the introduction is now clearer.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

First use (in intro) of "Ethernet Segments" add "(ES)" since ES and ESI are
used later. On second use (with multi home) please indicate whether that is
equivalent to non-null ESI and virtual ES since they seem to be used
interchangeably later.

[Jorge] ok, text added.

"
Since there are no multi-homed ES defined, the PEs keep their Attachment
Circuits active as long as the physical connectivity is established and the CEs
are responsible for managing the redundancy, avoiding loops and providing
per-I-SID load balancing to the PBB-EVPN network. " This makes sense but a
reference to a spec that explains that in details (: to the dumb reader :)
would be appreciated. Is this all in RFC7623?

[Jorge] no, not really. Added reference specs describing G.8032 and A/S PWs.

"
For instance, CE2 will block its link to CE1 and CE3 will block its forwarding
path to PE4. " I understand that's the normal before-failure condition, like
having the ring open between CE1 and CE2. Suggestion:

"
For instance, in normal conditions, CE2 will block its link to CE1 and CE3 will
block its forwarding path to PE4. "


[Jorge] done

On first use of the BMAC/X format please clarify that it means BMAC/ISID. This
appears later but without clarification.

[Jorge] it is clarified now

Thx
Jorge

From: Pascal Thubert via Datatracker 
Date: Monday, August 7, 2023 at 8:24 AM
To: int-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-pbb-evpn-isid-cmacflush@ietf.org 
, last-c...@ietf.org 

Subject: Intdir telechat review of draft-ietf-bess-pbb-evpn-isid-cmacflush-08


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.



Reviewer: Pascal Thubert
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
draft-ietf-bess-pbb-evpn-isid-cmacflush-08. 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/
.

Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.

The following are other issues I found with this document that SHOULD be
corrected before publication:

Please indicate how the CE can know if the PW failure is not due to the PE
failure, in which case extending the Customer MAC flush solution in RFC7623
seems more efficient as all I-SIDs with link / PW starting there are affected.
And how the double flush in avoided in the case of a non-null ESI with this
spec on as well.


I found this
"
When I-SID-based C-MAC-flush is disabled, the PE will follow the [RFC7623]
procedures for C-MAC-flush. " but it does not answer either of the above. e.g.,
does the reciprocal of the above apply too? or can they be both on?

I'd have thought that upon loss of connectivity with PE3, CE3 enables the PW to
PE4 and tells PE4 to send the update. Now it seems that the main player of this
spec is actually PE4 and that it's death is reported some other way. If that's
correct, saying it earlier would have saved me a headache ;)

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

First use (in intro) of "Ethernet Segments" add "(ES)" since ES and ESI are
used later. On second use (

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

[Jorge Rabadan (Nokia)]

Hi John,

Thanks for the review. Your comments have been addressed in version 09.

Please see in-line.

Thx
Jorge

From: John Scudder via Datatracker 
Date: Friday, August 4, 2023 at 6:27 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: John Scudder'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.



John Scudder 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:
--

- General: I'm taking it on faith that the flush procedures are properly
specified in one of the underlying specs. This one doesn't, it just is an
overlay that says "do the flush procedure but with this different trigger".
[Jorge] that is precisely the intent. RFC7623 specifies the technology and how 
C-MACs are flushed. This document is a delta of that.


- General: G.8032 should be at least an Informative reference.
[Jorge] added, thanks


- Section 1.1: Terms defined but never used, or used only once (so could be
inline)
  - B-Component (used only once)
  - vES (never used)
  - I-Component (only used once)
  - RD and RT are used only once, too
[Jorge] all fixed, thanks.


- Section 2(d), It's not obvious to me what "double flushing" means (and I do
know something about route reflectors).
[Jorge] this is really a leftover from old discussions that used other 
alternatives for C-MAC flush. I don’t think the double flushing discussion was 
due to the RR. I changed the text to the following (to avoid confusion):
“The solution MUST provide a reliable C-MAC-flush notification in PBB-EVPN 
networks that use Route-Reflectors (RRs). MAC flushing needs to be provided to 
all affected I-SIDs in spite of the BGP flush notification messages being 
aggregated at the RR.”


- Section 3, "The MAC Mobility extended community is used as in [RFC7623],
where a delta in the sequence number between two updates for the same
B-MAC/I-SID will be interpreted as a C-MAC-flush notification for the
corresponding B-MAC and I-SID", it seems to me that "a delta in the sequence
number" is a more casual description than is warranted? Looking at RFC 7423, it
appears the sequence number has to be incremented (modulo sequence wrap), not
just different (which is what "delta" implies). I guess a simple fix would be
s/a delta/an increment/. (Occurs again in Section 4.2, and again in Section
4.3. Just grep for "delta".)
[Jorge] it is a subtle but very good point. I fixed it in all the occurrences. 
Thanks.


- Section 4, where you write "Enabling or disabling I-SID-based C-MAC-flush
SHOULD be an administrative choice on the system that MAY be configured per
I-SID (I-Component). When enabled on a PE:", do you really mean the MAY to be
interpreted in the sense of RFC 2119, i.e. it's completely optional? Or do you
mean "may"?
[Jorge] it really meant MAY… we tried to clarify by adding the following, let 
us know if it helps:
“Enabling or disabling I-SID-based C-MAC-flush SHOULD be an administrative 
choice on the system that MAY be configured per I-SID (I-Component, Service 
Instance Component), as opposed to being configured for all I-SIDs.”


- Section 5(e), "The solution can coexist in a network with systems supporting
or not supporting this specification." I guess the coexistence with
non-supporting systems is that they just ignore the new style of route, and
have to age out the MACs the old-fashioned way (with concomitant loss of
traffic)?
[Jorge] Yes, ignore and follow RFC7623, which provides c-mac flush for Ethernet 
Segments but not for other redundant connections. I completed the sentence as 
follows:
“The solution can coexist in a network with systems supporting or not 
supporting this specification. Non-supporting systems ignore the B-MAC/I-SID 
routes, however they still follow the C-MAC-flush procedures in RFC7623”


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

[bess] I-D Action: draft-ietf-bess-pbb-evpn-isid-cmacflush-09.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-pbb-evpn-isid-cmacflush-09.txt is now
available. It is a work item of the BGP Enabled ServiceS (BESS) WG of the
IETF.

   Title:   PBB-EVPN ISID-based C-MAC-Flush
   Authors: Jorge Rabadan
Senthil Sathappan
Kiran Nagaraj
M. Miyake
T. Matsuda
   Name:draft-ietf-bess-pbb-evpn-isid-cmacflush-09.txt
   Pages:   13
   Dates:   2023-10-23

Abstract:

   Provider Backbone Bridging (PBB) can be combined with Ethernet
   Virtual Private Networks (EVPN) to deploy Ethernet Local Area Network
   (ELAN) services in large Multi-Protocol Label Switching (MPLS)
   networks.  That combination is what we refer to as PBB-EVPN.  Single-
   Active Multi-homing and per-I-SID (per Service Instance Identifier)
   Load-Balancing can be provided to access devices and aggregation
   networks.  In order to speed up the network convergence in case of
   failures on Single-Active Multi-Homed Ethernet Segments (ES), PBB-
   EVPN defines a flush mechanism for Customer MACs (C-MAC-flush) that
   works for different Ethernet Segment Backbone MAC (B-MAC) address
   allocation models.  This document complements those C-MAC-flush
   procedures for cases in which no PBB-EVPN Ethernet Segments are
   defined (the attachment circuit is associated to a zero Ethernet
   Segment Identifier) and a Service Instance Identifier based (I-SID-
   based) C-MAC-flush granularity is required.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-pbb-evpn-isid-cmacflush-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-pbb-evpn-isid-cmacflush-09

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] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Ketan Talaulikar]

Hi Matthew,

We have just posted the WG version of the draft that is identical to the
one that was up for adoption.

We will post another update after incorporating the changes to address
Bruno's comments after we conclude on the text changes.

Thanks,
Ketan


On Wed, Oct 18, 2023 at 4:10 PM Matthew Bocci (Nokia) <
matthew.bo...@nokia.com> wrote:

> WG,
>
>
>
> There is consensus to adopt this draft as a BESS WG document.
>
>
>
> Authors: please respond to the one comment form Bruno and upload a new
> version of the draft as draft-ietf-bess-bgp-srv6-args-00.
>
>
>
> Thanks
>
>
>
> Matthew
>
>
>
> *From: *Matthew Bocci (Nokia) 
> *Date: *Thursday, 28 September 2023 at 15:49
> *To: *bess@ietf.org 
> *Cc: *draft-trr-bess-bgp-srv6-a...@ietf.org <
> draft-trr-bess-bgp-srv6-a...@ietf.org>
> *Subject: *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)
> 
>
___
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

[Ketan Talaulikar]

Hi Bruno,

Thanks for your support and comments. Please check inline below for
response.

On Wed, Oct 11, 2023 at 7:51 PM  wrote:

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

KT> Ack. We will incorporate this change in the next version.


> §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.
>
>
KT> In this context, the "proper" values are the same values as signaled
via the SID Structure for the End.DT2M SID. Would the following work?

NEW:
it is
REQUIRED that the LBL, LNL, and FL values be set as indicated via
the 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”).
>
>
KT> Perhaps the word "appropriate" is redundant here ... would removing it
help?

Thanks,
Ketan


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