Re: [Apn] Problem statement

[Ted Hardie <[e-mail]>]

Hi Shuping,

Some comments in-line.

On Thu, May 4, 2023 at 2:53 AM Pengshuping (Peng Shuping) <pengshuping=
[e-mail]> wrote:

> Hi all,
>
>
>
> We now start working to craft a problem statement and trying to clarify
> the problem space to be addressed. The following text describing the
> problem was produced while talking with people during IETF116 and other
> activities later. Maybe we could take this as a starting point. Your
> comments and suggestions are appreciated.
>
>
>
> The text is also uploaded in Github.
>
> https://github.com/APN-Github/Problem-statement
>
>
>
> ================
>
>
>
> In a network operator controlled domain, the ingress edge devices usually
> have access to much richer information, such as VLAN/QinQ, VPN, and access
> interface, which is used to classify the packets into fine granular virtual
> groups of flows at the edge. However, after the packets enter the network
> operator’s domain, all such information is lost together with the
> continuous fine granularity within the network.
>

"all such information is lost together with the continuous fine granularity
within the network" seems to be the core of the problem statement.  I think
it is not quite correct as stated, in that the information is not lost; it
is distributed.  Because this is within a single operator's domain, the
operator can construct the network to map data like VLAN to specific
address announcements or DHCP assignments; even if there is a later NAT or
CGNAT, the operator should control all of the devices which implement those
mappings.  That means the operator has (or can have) this information now;
it's just distributed through the network.

I think you need to be clear about this because it makes it more obvious
that you are describing a potential optimization, rather than truly new
functionality.

I also believe that you need to include a statement about what the network
is going to do with the "fine grained information", because you can't judge
whether a proposal serves the purpose adequately without that.   If your
aim is to carry it to an orchestrator inside an operator network for action
(as in the source quench example Adrian came up with), then this is a way
of getting data to that orchestrator rather than using a set of database
dips.  That has one set of characteristics, and my personal guess is that
it would look much like service function chaining.

If your aim is to affect research consumption within the network, then
you'd both need different data and you need the entire network to provide
queues at the level of granularity that you're proposing.  As you point
out, most things currently get mapped to things like DSCP or EXP, and I
invite you to consider the tradeoff between complex queue management and
additional capacity in that reality.

I also thought there was consensus that this proposal needed to have
privacy considerations so that the same data that carries ingress port
information did not carry information specific to the user.  While I am
sure that the proponents are clear on this limitation, I think it would be
appropriate to repeat that in the problem statement text, as that would
help new participants understand that it is firmly out of scope.

best regards,

Ted Hardie

Indeed, the information is mapped into small fields like DSCP (6 bits) or
> MPLS EXP (3 bits). However, such small fields are only able to provide
> relatively coarse grained QoS treatment. The packet treatments needed may
> vary at different parts of the packet’s path within the domain, and enough
> information is needed to determine these treatments. Thus, the continuous
> fine grained network services within the network domain cannot be provided
> efficiently. This information can be carried directly in the packet or
> achieved through a mapping from an opaque tag. Existing protocols such as
> SFC/NSH, SR/SRv6, MPLS, VXLAN, and IPv6, can be taken as implementation
> basis, but in each case the protocol may need extensions.
>
>
>
> =================
>
>
>
> Best Regards,
>
> Shuping
> --
> Apn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apn
>