Re: [bess] I-D Action: draft-ietf-bess-evpn-oam-req-frmwk-05.txt

2021-02-17 Thread Donald Eastlake 
This revision includes responses to the Last Call comments and minor
editorial improvements.

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

On Wed, Feb 17, 2021 at 3:43 PM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title   : EVPN Operations, Administration and Maintenance 
> Requirements and Framework
> Authors : Samer Salam
>   Ali Sajassi
>   Sam Aldrin
>   John E. Drake
>   Donald E. Eastlake
> Filename: draft-ietf-bess-evpn-oam-req-frmwk-05.txt
> Pages   : 20
> Date: 2021-02-17
>
> Abstract:
>This document specifies the requirements and reference framework for
>Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).
>The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider
>Backbone Bridge EVPN).  The framework defines the layered OAM model
>encompassing the EVPN service layer, network layer, underlying Packet
>Switched Network (PSN) transport layer, and link layer but focuses on
>the service and network layers.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-oam-req-frmwk-05
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-oam-req-frmwk-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-oam-req-frmwk-05
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

[bess] I-D Action: draft-ietf-bess-evpn-oam-req-frmwk-05.txt

2021-02-17 Thread internet-drafts 


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

Title   : EVPN Operations, Administration and Maintenance 
Requirements and Framework
Authors : Samer Salam
  Ali Sajassi
  Sam Aldrin
  John E. Drake
  Donald E. Eastlake
Filename: draft-ietf-bess-evpn-oam-req-frmwk-05.txt
Pages   : 20
Date: 2021-02-17

Abstract:
   This document specifies the requirements and reference framework for
   Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).
   The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider
   Backbone Bridge EVPN).  The framework defines the layered OAM model
   encompassing the EVPN service layer, network layer, underlying Packet
   Switched Network (PSN) transport layer, and link layer but focuses on
   the service and network layers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-oam-req-frmwk-05
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-oam-req-frmwk-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-oam-req-frmwk-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


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

Re: [bess] Please send request to take slot in IETF 110

2021-02-17 Thread Linda Dunbar 
Mankamana, and BESS chair,

Can we have 10 minutes slot to go through the major changes in the latest 
revision of
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/?

Primarily on the Packet Walk Through which we didn’t cover at IETF 109.

Linda

From: BESS  On Behalf Of Mankamana Mishra (mankamis)
Sent: Tuesday, February 16, 2021 9:58 AM
To: bess@ietf.org
Subject: [bess] Please send request to take slot in IETF 110

All,
Agenda for IETF 110 is out. Please send request to take slot to present.  We 
are meeting on March 10th

13:00-15:00
Wednesday Session I



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

Re: [bess] Is there any issue with the changes to the Packet Walk-Through for BGP SDWAN usage ?

2021-02-17 Thread Linda Dunbar 

Basil,

Thank you very much for the suggestion. Has incorporated your comments to the 
03 version.

Linda
From: Najem, Basil 
Sent: Tuesday, February 16, 2021 6:48 PM
To: Linda Dunbar ; bess@ietf.org
Subject: RE: Is there any issue with the changes to the Packet Walk-Through for 
BGP SDWAN usage ?

Hi Linda;

SD-WAN Service is a Layer 3 (IP based) Service. However, the SD-WAN node (at 
the client's site) can either learn the client's prefixes using routing 
protocol (the common case) or other ways (e.g. direct connection to the CN).

I propose the following text:

"SDWAN node can learn client routes via the client facing ports using IP 
routing protocol (e.g.OSPF, RIP, BGP or Static routes). "

Re CNx: if each CNx is a distinct client network with a distinct prefix (e.g. 
192.168.1.0/24), then this should be captured in the document for clarity.

Best Regards;

Basil
From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: January-28-21 1:32 PM
To: Najem, Basil mailto:basil.na...@bell.ca>>; 
bess@ietf.org
Subject: [EXT]RE: Is there any issue with the changes to the Packet 
Walk-Through for BGP SDWAN usage ?

Basil,

You asked a really good question "can you please explain how RFC8388 is used to 
learn the client prefixes in this scenario?"

SDWAN services to clients can be IP based or Ethernet based. RFC8388 has 
specified necessary parameters to be configured for Ethernet based services to 
clients. For IP based services, clients routes can be learned via OSPF, RIP, 
BGP or statically configuration. The mapping from clients routes to SDWAN 
Segmentation Identifier have to be configured.

Do you think the following description is clear enough?
"SDWAN services to clients can be IP based or Ethernet based. For IP based 
services, an SDWAN node can learn client routes from the client facing ports 
via OSPF, RIP, BGP or Statically configuration. If the SDWAN services are layer 
2 services, the relevant EVPN parameters, such as the ESI (Ethernet Segment 
Identifier), EVI, CE-VID to EVI mapping have to be configured in the same way 
as EVPN described in RFC8388. "


The CNx in Figure 2 represents a Client Network.  Some CN can be multi-homed to 
two PEs (which is not shown in the figure for -02 revision, will be updated for 
-03 revision).

Linda Dunbar

From: Najem, Basil mailto:basil.na...@bell.ca>>
Sent: Wednesday, January 27, 2021 9:19 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
bess@ietf.org
Subject: RE: Is there any issue with the changes to the Packet Walk-Through for 
BGP SDWAN usage ?

Dear Linda;

Is CNx in Figure 2 represents a distinct IP prefix? If yes, this must be added 
to the description.

The SD-WAN node can learn the local client's prefixes (i.e. the client prefixes 
that are connected directly to the node) via a routing protocol (e.g. OSPF, 
BGP); can you please explain how RFC8388 is used to learn the client prefixes 
in this scenario? More explanation is warranted here.

Regards;

Basil
From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Linda Dunbar
Sent: January-27-21 12:09 PM
To: bess@ietf.org
Subject: [EXT][bess] Is there any issue with the changes to the Packet 
Walk-Through for BGP SDWAN usage ?

BESS WG:

We recently made some changes to the Packet Walk-Through for BGP SDWAN usage 
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/
 .
Since the draft is already a WG draft, want to solicit feedback from the WG if 
the changes are appropriate.

5.1Packet Walk-Through for Scenario #1 (Homogeneous WAN)
(This is referring to a type of SDWAN network with edge nodes encrypting all 
traffic over WAN to other edge nodes, regardless of whether the underlay is 
private or public.).

A single IPsec security association (SA) protects data in one direction. Under 
the Scenario #1, two SAs must be present to secure traffic in both directions 
between any two end points, which can be two C-PE nodes, two client ports, or 
two prefixes.
Upon power up, a SDWAN node can learn client routes from the Client facing 
ports in the same way as EVPN described in RFC8388. Controller, i.e. BGP-RR, 
facilitates the IPsec SA establishment and rekey management as described in 
[SECURE-EVPN]. Controller manages how client's routes are associated with 
individual IPSec SA.
Using Figure 2 of the Section 3.2 as an example. Let's assume that the IPsec 
SAs terminate at the C-PE nodes. To enable full mesh communication within 
client CN2 that are attached to C-PE1, C-PE3, and C-PE4, six one