Re: [bess] (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

[Linda Dunbar <[e-mail]>]

Basil,

Thanks for the call to make your points clear.
Now the section 3.1 is as follows. The EVPN and IPVPN service requirement are moved to Section 3.4. Scenario #3: Private VPN PE based SD-WAN.  Please let me know if those changes have addressed your concern.

Linda
---------------------

3.1.2. Client Service Requirement
The client service requirements describe the port interface requirement at the SD-WAN edge to connect the client network to the SD-WAN service.
The client interface ports can support IPv4 & IPv6 address prefixes and Ethernet (as described in [IEEE802.3] standard).
It is worth noting that this "interface" is called SD-WAN UNI in [MEF 70.1] with a set of attributes (described in Section 11 in MEF 70.1); these attributes (in MEF 70.1) describe the expected behavior and requirements to support the connectivity to the client network.
The client service should support the SD-WAN UNI service attributes at the SD-WAN edge as described in MEF 70.1, Section 11.



From: Najem, Basil <[e-mail]>
Sent: Tuesday, November 21, 2023 1:24 PM
To: Linda Dunbar <[e-mail]>
Cc: [e-mail]
Subject: RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Hi Linda;

The SD-WAN Edge has client-interface (which is covered by my updated text); the WAN interface, which is facing the underlay demark device, doesn't need EVPN. The SD-WAN Edge WAN interface is meant to connect the SD-WAN Edge to the underlay demark device (e.g. IPVPN CE router) and it typically uses IP connectivity (l3) with  Ethernet (IEEE 802.3 std) (L2). Not sure how the EVPN would be needed for the SD-WAN Edge.

I am happy to have a live chat with you if that works for you.

Best Regards;

Basil
From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: November-21-23 1:51 PM
To: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT]RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Basil,

I now see your points.

Since IETF is more about the network side protocol,  the client service requirements not only describe the port interface requirement at the SD-WAN edge to connect the client network to the SD-WAN service but also  the requirement from the network side to support the client services.

Linda

From: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 21, 2023 12:38 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Hi Linda;

The question is: which interface we are talking about? If it's the client-facing interface (which is what this section is about(, then we don't need EVPN.

Best Regards;

Basil
From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: November-21-23 1:36 PM
To: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT]RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Basil,

We are talking about the EVPN service requirement as described in Section 3.1 of RFC8388 are applicable to the SD-WAN Ethernet-based Client services.

Linda

RFC 8388:

3.1.  Service Requirements

   The following service requirements are assumed in this scenario:

   o  Redundancy requirements:

      -  CE2 requires multihoming connectivity to PE1 and PE2, not only
         for redundancy purposes but also for adding more upstream/
         downstream connectivity bandwidth to/from the network.

      -  Fast convergence.  For example, if the link between CE2 and PE1
         goes down, a fast convergence mechanism must be supported so
         that PE3 can immediately send the traffic to PE2, irrespective
         of the number of affected services and MAC addresses.

   o  Service interface requirements:

      -  The service definition must be flexible in terms of CE-VID-to-
         broadcast-domain assignment in the core.


From: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 21, 2023 12:20 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Hi Linda;

Are we talking about the interface to the client network (which is what we are talking about in this section ) OR you are talking about the WAN interface (which is NOT what we are talking about)?

Best Regards;

Basil
From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: November-21-23 1:18 PM
To: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT]RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Basil,

EVPN refers to the network side to support Ethernet based services.

Linda

From: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 21, 2023 12:12 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Hi Linda;

The MEF 70.1 UNI Service attributes do cover what's required for the client service; typically this interface (facing the client network) doesn't need to support EVPN. Therefore, we don't need this paragraph.

Best Regards;

Basil
From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: November-21-23 12:39 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Najem, Basil <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT]RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Basil,

Actually, the following requirement has not been covered by the text you provided:
".. that EVPN service requirements apply to client traffic, as described in Section 3.1 of RFC8388. "

I think we need to keep the text in the document.

Linda


From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 21, 2023 11:30 AM
To: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Basil,

I just upload the v18. I will make the change, wait for other LC reviews, and upload the v19.

Linda

From: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 21, 2023 11:28 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

You are very welcome Linda;

For the Client Service Requirement Section, you need to delete the following paragraphs as they were covered by the new paragraph:
For Ethernet-based client traffic, an SD-WAN edge should support VLAN-based service interfaces (EVPN Instances), VLAN bundle service interfaces, or VLAN-Aware bundling service interfaces. EVPN service requirements apply to client traffic, as described in Section 3.1 of RFC8388.
For IP-based client interfaces, L3VPN service requirements are applicable.



Best Regards;

Basil


From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: November-21-23 11:56 AM
To: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT]RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Basil,

Thank you very much for the suggested wording. Please see the attached revision with your suggested wording added.

Linda

From: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 20, 2023 2:08 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Subject: RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Hi Linda;

I reviewed the document and suggest to change the Client Service Requirement section to the following:

The client service requirements include:
The client service requirements describe the port interface requirement, at the SD-WAN edge, to connect the client network to the SD-WAN service. The client interface ports can support IPv4 & IPv6 address prefixes, as well as, Ethernet (as described in IEEE 802.3 standard).
It worth nothing that this "interface" is called SD-WAN UNI in MEF 70.1 with a set of attributes (described in Section 11 in MEF 70.1); these attributes (in MEF 70.1) describe the expected behavior and requirements to support the connectivity to the client network.
The client service requirement, at the SD-WAN edge, should support the SD-WAN UNI service attributes as described in MEF 70.1, Section 11.


Also, I did review Scenario#3 (Section 3.4) and I propose the following paragraph (to replace the existing one in V. 18 before Figure 4):

1.1. Scenario #3: Private VPN PE based SD-WAN
This scenario refers to an existing VPN (e.g., EVPN or IPVPN) being expanded by adding extra ports facing the public Internet to accommodate any additional bandwidth requirement between two PEs.
Here are some differences from the Hybrid Underlay scenario (Section 3.3):

     *   For MPLS-based VPN, PEs would have MPLS as payload encapsulated within the IPsec tunnel egressing the Internet WAN ports, MPLS-in-IP/GRE-in-IPsec.
     *   The BGP RR is connected to PEs in the same way as VPN, i.e., via the trusted network.


PE-based SD-WAN can be used by VPN service providers to temporarily increase bandwidth between sites when not sure if the demand will sustain for an extended period or as a temporary solution prior to building or leasing a permanent infrastructure.



Best Regards;

Basil

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: November-17-23 5:12 PM
To: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT]RE: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Basil,

Can you please check if the v.18 attached have addressed all your comments?

Linda

From: Najem, Basil <[e-mail]<mailto:[e-mail]>>
Sent: Friday, November 17, 2023 11:55 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Subject: (FW: WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

Will do Lina;

Wanted to know when are you going to post the v.18 of the document?

Regards;

Basil


From: BESS <[e-mail]<mailto:[e-mail]>> On Behalf Of Matthew Bocci (Nokia)
Sent: Thursday, November 16, 2023 5:49 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [bess] WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

This email begins a second working group last call for draft-ietf-bess-bgp-sdwan-usage-17 - BGP Usage for SD-WAN Overlay Networks<https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/>

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 and the document re-adopted by the working group. We are now going through a quick WG last call.

An IPR poll was completed on the previous version of the draft for which we requested publication.

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

This poll will close on Friday 24th November.

Regards

Matthew
________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints