inbound/outbound terminology

[julianL999]

RFC8299 and RFC8466 use "inbound-bandwidth" and "outbound-bandwidth" from the point of view of the customer site.

L3NM also uses this terminology from the point of view of the customer's site.
L2NM flips the terminology, for example "inbound" is from PE's perspective.

To avoid confusion, it would better in both L3NM and L2NM to use explicit terminology so that the direction is obvious, e.g.

"PE-to-CE-bandwidth"
"CE-to-PE-bandwidth"

In the description field, it would be good to say which field in RFC8299/RFC8466 this corresponds to.

[segevere]

practically it is ingress-Policer and egress-Shaper, because the BW is controlled only from the PE side.
in addition there is policer and shaper per CoS/Queue which should be addressed.

[boucadair]

Hi Julian,

RFC8299 and RFC8466 use "inbound-bandwidth" and "outbound-bandwidth" from the point of view of the customer site.

I guess you meant "input-bandwidth" and "output-bandwidth".

L3NM also uses this terminology from the point of view of the customer's site.

We do have the following for the L3NM:

'inbound-bandwidth': Indicates, in bits per second (bps), the
inbound bandwidth of the connection (i.e., download bandwidth from
the service provider to the site).

'outbound-bandwidth': Indicates, in bps, the outbound bandwidth of
the connection (i.e., upload bandwidth from the site to the
service provider).

L2NM flips the terminology, for example "inbound" is from PE's perspective.

We do have the same definitions as in the L2NM

  'svc-inbound-bandwidth' indicates the inbound bandwidth of the
  connection (i.e., download bandwidth from the service provider to
  the site).

  'svc-outbound-bandwidth' indicates the outbound bandwidth of the
  connection (i.e., upload bandwidth from the site to the service
  provider).

To avoid confusion, it would better in both L3NM and L2NM to use explicit terminology so that the direction is obvious, e.g.

"PE-to-CE-bandwidth" "CE-to-PE-bandwidth"

In the description field, it would be good to say which field in RFC8299/RFC8466 this corresponds to.

Please note that we do already have the following in the common I-D:

     "Indicates support for the inbound bandwidth in a VPN. That is,
      support for specifying the download bandwidth from the service
      provider network to the VPN site. Note that the L3SM uses
      'input' to identify the same feature. That terminology should
      be deprecated in favor of the one defined in this module.";

Which was echoed in the L3NM, e.g.,

                     "Note that the L3SM uses 'input-
                      -bandwidth' to refer to the same concept.";

[julianL999]

Hi Med

In https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm-09 it says as follows, maybe it is a typo?

container svc-outbound-bandwidth {
if-feature "vpn-common:outbound-bw";
description
"From the PE perspective, the service outbound
bandwidth of the connection.";

But I would urge you to change the terminology to "PE-to-CE-bandwidth" /"CE-to-PE-bandwidth" to make it super-explicit, the current terminology has been causing endless confusion to implementers (I realise it's inherited from the service models, but changing the terminology in LXNM would cure the problem well)

[boucadair]

container svc-outbound-bandwidth {
if-feature "vpn-common:outbound-bw";
description
"From the PE perspective, the service outbound
bandwidth of the connection.";

This is a typo. It needs to be fixed.

But I would urge you to change the terminology to "PE-to-CE-bandwidth" /"CE-to-PE-bandwidth" to make it super-explicit, the current terminology has been causing endless confusion to implementers (I realise it's inherited from the service models, but changing the terminology in LXNM would cure the problem well)

Will move this one to the list.

[boucadair]

Julian, please check the PR at 7e5286a

[julianL999]

Julian, please check the PR at 7e5286a

Med, this is great, thanks! Can it be changed similarly in L3NM as well?

Julian