TAPI Ethernet: EthCtpPac/vlanConfig

[amazzini]

The vlanConfig attribute of EthCtpPac should be a table, rather than a single integer. Same comment applies to G.8052-v2.03, where the VlanConfigSink/Source_Pac foresee single integer, and are referenced by ETH_ConnectionTerminationPointSink/Source with multiplicity 0..1

[bzeuner]

G.8021 defines the MI_VLAN_Config as a list [1...M]. [1...M] is identifying the list of client Ethernet CTPs. The VlanConfigSink/Source_Pac is associated to such a client Ethernet CTP which means that there is only one MI_VLAN_Config per CTP.

G.8021 defines for So_MI_VLANConfig: "The MI_VLANConfig input parameter determines for every input port the associated VID value. The allowed values for the VID signal are untagged, priority tagged and 1-4094." G.8021 defines for Sk_MI_VLANConfig: "The MI_Vlan_Config parameter specifies the possible VID values for the ports to be used. If there is no port assigned to a specific VID value and this VID value is used, the VID Demux process will filter the incoming signal set. Disabling the ingress VID filtering is modelled by setting MI_VlanConfig [1…4094]. "

Therefore, the vlanConfig need to be a single attribute which could have the following values:

• untagged
• priority tagged
• 1-4094 (also non adjacent ranges like 10..20 | 100..120 | 200)

[italobusi]

I think the issue is caused by a lack of common understanding about how to use the TAPI core model to model VLAN bundling (ETHG in G.8021)

I think Andrea is assuming that in this case we have one connection while Bern is assuming we have multiple co-routed connections

If we have one connection, then that EthCtpPac should specify the set of VLAN IDs which are "bundled" together

If we have multiple connections, then the EthCtpPac should specify only one VLAN ID

In the latter case it is not fully clear how the different connections are bundled together and how the co-routing requirement is described

[bzeuner]

The VLAN_Config parameter is defined for the VLAN bundling case

• ETHx/ETHG_A_So_MI_VLAN_Config[1...M]
• ETHx/ETHG_A_Sk_MI_VLAN_Config[1...M]

and also for the "normal" VLAN multiplexing case

• ETHx/ETH-m_A_So_MI_VLAN_Config[1...M]
• ETHx/ETH-m_A_Sk_MI_VLAN_Config[1...M]

[amazzini]

MEF 10.3: "Bundling Enabled is compatible with Service Multiplexing". Hence I would recommend to model one connection. May G.8052 represent a G.8021 ETHG as single CTP?

[italobusi]

@bzeuner : The current definition of the ETHx/ETHG_A in G.8021 is not fully clear to me. At the first glance I do not see differences between the ETHx/ETH-m_A and the ETHx/ETHG_A atomic functions. Let's have some check with ITU-T experts

[italobusi]

@amazzini : I do not understand the rationale for your conclusion (i.e., the "hence")

I think the fact that "Bundling Enabled is compatible with Service Multiplexing" requires VLAN bundling to be supported by the ETHx/ETH-m_A atomic functions (hence my question/doubt about the need for the ETHx/ETHG_A atomic functions)

I think that modelling VLAN bundling as multiple "bundled" connections meet the MEF 10.3 requirements since these connections can be multiplexed with other connections on the same UNI,

Another subtle issue to consider is that G.8021 models the ETHG as a TCM MEP (not as an NCM MEP).

This seems correct to me since each individual VLAN should represent an independent "trail" otherwise why assigning different VLAN IDs?

However, these different end-to-end connections can be managed as a bundled SNC within a domain and monitored as a single MEG

[amazzini]

@italobusi Because the subject is a network management model - hence for management perspective, there is no rationale to model a "bundle" of connections.

[karthik-sethuraman]

TAPI Call April 17, 2018 Notes: https://wiki.opennetworking.org/display/OTCC/2018-04-17+TAPI+Meeting+Notes

ETHG (group of VLAN IDs) is used for OAM purposes where only a single VLAN is monitored https://wiki.opennetworking.org/download/attachments/317620231/image2018-4-17%2010%3A38%3A8.png?version=1&modificationDate=1523975890888&api=v2

All VLANs in ETHG has to be co-routed, but beyond the scope of the OAM ME/MA, each of these VLANs may have separate route. Thus ETHG is not necessarily E2E. But from an UNI-N side, all these VLANs are/should be bundled. So effectively they are a single connection https://wiki.opennetworking.org/download/attachments/317620231/image2018-4-17%2011%3A1%3A4.png?version=1&modificationDate=1523977267089&api=v2

Is the below valid to model or monitor as a bundled-connection even if they belong to different services and if they are co-routed in the transit domain. No if needs to be done, OVC (S-Tags) has to be used. https://wiki.opennetworking.org/download/attachments/317620231/image2018-4-17%2010%3A53%3A16.png?version=1&modificationDate=1523976799048&api=v2

[amazzini]

This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.