Add vpws local and remote identifiers to EVPN-VPWS configuration

[crcampos612]

• Add local and remote vpws service instance identifier (ethernet-tag) that identifies the local and remote attachment circuit (AC) ends of the emulated service as per RFC 8214.

Change Scope

• Current connection-point in network-instance model doesn't fit into the VPWS approach where there is no need to explicitly set the remote endpoint address as they are autodiscovered by BGP in respective PE endpoints. Besides, a field to enter the local virtual circuit identifier doesn't exist either.
• Therefore, the proposal is to extend openconfig-evpn.yang model with those two new for setting both local and remote vpws service identifiers within container evpn/evpn-instances/evpn-instance

Platform Implementations

• Cisco:
  https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-8/lxvpn/configuration/guide/b-l2vpn-cg-asr9000-78x/evpn-virtual-private-wire-service.html
• Juniper:
  https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/example/example-configuring-vpws-service-with-evpn-signaling-mechanisms.html
• Huawei:
  https://support.huawei.com/enterprise/en/doc/EDOC1000173015/229228a3/configuring-evpn-vpws-over-mpls-functions
• Nokia:
  https://infocenter.nokia.com/public/7750SR225R1A/index.jsp?topic=%2Fcom.nokia.L2_Services_and_EVPN_Guide%2Fevpn_for_mpls_t-ai9enrmqfa.html

Examples

CISCO

evpn
 evi 9999
  bgp
   rd 27699:31133
   route-target import 27699:31133
   route-target export 27699:31133

l2vpn
 xconnect group ELINE_VPWS_CISCO_GROUP
  p2p ELINE_VPWS_AC_1
   interface TenGigE0/0/0/15
   neighbor evpn evi 9999 target 111 source 333

JUNIPER

set routing-instances EVPN-VPWS instance-type evpn-vpws
set routing-instances EVPN-VPWS interface ae0.100
set routing-instances EVPN-VPWS route-distinguisher 198.51.100.1:11
set routing-instances EVPN-VPWS vrf-target target:100:11
set routing-instances EVPN-VPWS protocols evpn interface ae0.100 vpws-service-id local 1111
set routing-instances EVPN-VPWS protocols evpn interface ae0.100 vpws-service-id remote 9999

HUAWEI

evpn vpn-instance ELINE_VPWS_AC_1 vpws
route-distinguisher 27699:451123
vpn-target 27699:1123 export-extcommunity
vpn-target 27699:1123 import-extcommunity

evpl instance 9999
evpn binding vpn-instance ELINE_VPWS_AC_1
local-service-id 333 remote-service-id 111

NOKIA

epipe 9999 name "ELINE-VPWS-AC-1" customer 1 create
			bgp
                route-distinguisher 27699:511531
                route-target export target:27699:511531 import target:27699:511531
            exit
            bgp-evpn
                local-ac-name "AC-HEAD-END"
                    eth-tag 333
                exit
                remote-ac-name "AC-TAIL-END"
                    eth-tag 111
                exit
                evi 9999

[OpenConfigBot]

Major YANG version changes in commit b3a9921c7acb89108d77fa105390abf1fce6eafe:

[OpenConfigBot]

Compatibility Report for commit 963ec5225b9c0c94537dc3e1851ce67fa4718a9a: ✅ pyangbind@1b7ee10

[dplore]

        +--rw evpn
        |  +--rw evpn-instances
        |  |  +--rw evpn-instance* [evi]
        |  |     +--rw evi                     -> ../config/evi
        |  |     +--rw config
        |  |     |  +--rw evi?                      string
        |  |     |  +--rw encapsulation-type?       identityref
        |  |     |  +--rw service-type?             identityref
        |  |     |  +--rw multicast-group?          oc-inet:ip-address
        |  |     |  +--rw multicast-mask?           oc-inet:ip-address
        |  |     |  +--rw replication-mode?         enumeration
        |  |     |  +--rw route-distinguisher?      union
        |  |     |  +--rw control-word-enabled?     boolean
        |  |     |  +--rw local-vpws-service-id?    uint32
        |  |     |  +--rw remote-vpws-service-id?   uint32
        |  |     +--ro state
        |  |     |  +--ro evi?                      string
        |  |     |  +--ro encapsulation-type?       identityref
        |  |     |  +--ro service-type?             identityref
        |  |     |  +--ro multicast-group?          oc-inet:ip-address
        |  |     |  +--ro multicast-mask?           oc-inet:ip-address
        |  |     |  +--ro replication-mode?         enumeration
        |  |     |  +--ro route-distinguisher?      union
        |  |     |  +--ro control-word-enabled?     boolean
        |  |     |  +--ro local-vpws-service-id?    uint32
        |  |     |  +--ro remote-vpws-service-id?   uint32
        |  |     +--rw import-export-policy
        |  |     |  +--rw config
        |  |     |  |  +--rw export-route-target*   union
        |  |     |  |  +--rw import-route-target*   union
        |  |     |  +--ro state
        |  |     |     +--ro export-route-target*   union
        |  |     |     +--ro import-route-target*   union

[dplore]

Reviewed at OC Operators meeting on Aug 1, 2023. Seems like Huawei and Nokia examples do not include an interface, but Cisco and Juniper do. Is the interface reference required to complete the configuration? Also, this model only allows one VPWS per network instance. Probably there should be a list of of the VPWS?

[jorabada]

Reviewed at OC Operators meeting on Aug 1, 2023. Seems like Huawei and Nokia examples do not include an interface, but Cisco and Juniper do. Is the interface reference required to complete the configuration? Also, this model only allows one VPWS per network instance. Probably there should be a list of of the VPWS?

In case of Nokia, our "network-instance" is defined as a generic point-to-point service, where you have interfaces and optionally you can have one interface plus an "evpn-instance". So there is a 1:1 mapping, and the interface is not included in the evpn-instance, but in the network-instance. As you do for the case of MAC-VRFs..

My suggestion would be to do something similar to the MAC-VRF with EVPN model, that is, an EVPN-VPWS service would be configured as follows:

• add a network-instance type L2P2P, with one interface
• add an evpn-instance, which includes the local and remote vpws-service-id

To satisfy models that support multiple VPWS per "routing-instance" (e.g. JunOS), we could define a new NETWORK_INSTANCE_TYPE, e.g. MULTI-L2P2P (or similar), and then for that type we could include the interface in the evpn-instance...

My two cents..

[oscargdd]

This PR was discussed in the public OC special meeting. An alternative proposal was discussed in which connection points were used and enhanced to be able to have multiple point-to-point connections in the same network instance reusing the same EVPN instance. All vendors implementing EVPN-VPWS support the one-to-one mapping case between point-to-point service, while not all support the case of reusing the EVPN insance. The consensus was that is was better to decouple both functions. Hence, with this PR, ONE Network instance will represent ONE point to point service with ONE EVPN instance (route distinguishsçer and target). The proposed solution in this PR was reasonable and implementable for the vendors present in the call. For the "multi Point to point connection" use case, a new type of network instance needs to be created. This will be done in a separate PR triggered by the need of that use case.

[dplore]

Last call expires today. Since there are no new comments, I will merge this.

/gcbrun

[dplore]

@oscargdd can you resolve the merge conflicts?

[wlin212]

A P2P service establish by VPWS is between a pair of ACs. Hence, it's essential to specify the local interface associated with a P2P service within an EVPN VPWS instance.  Each EVPN VPWS instance can accommodate one or more P2P services, provided each P2P service has its unique AC and its local VPWS service ID.  Therefore, it is crucial to ensure that we can incorporate multiple P2P services under the same EVPN VPWS instance.   Additionally, please ensure the inclusion of 'flow-label-enabled' for the EVPN VPWS instance.

I'm also curious about the 'multicast-group,' 'multicast-mask,' and 'replication-mode' attributes within an EVPN VPWS instance as these attributes do not apply to VPWS P2P services.  it might be worthwhile to remove them, but please let me know if I've overlooked any specific relevance or context.  

[oscargdd]

h EVPN VPWS instance can accommodate one or more P2P services, provided each P2P service has its unique AC and its local VPWS service ID.  Therefore, it is crucial to ensure that we can incorporate multiple P2P services under the same EVPN VPWS instance.

HI, in the public openconfig call we agreed on limiting the functionality of this use case to the one-to-one mapping case, which is the most common. There was another proposal, to add in another PR in which , with a different network instance type you can support multiple P2P over the same EVPN instance. Not all vendors support this way of working, that is why we decided to keep them separate.

[dplore]

Reviewed in today's in OC Operators meeting. Operators did not have a use case for 'flow-label-enabled' for the EVPN VPWS instance at this time. It seems like this could be added in a future PR, with the necessary references and operational use cases described.

@oscargdd can you respond regarding the presence of multicast-group multicast-mask and replication-mode leafs now that we are adding (local|remote)-vpws-service-id?

[dplore]

Re-reviewed in April 30, 2024 OC operators meeting. @oscargdd to resolve conflicts and respond on the multicast related leafs. Then I think this is ready to merge.