19. Is that "structured attribute" more accurate than “tag”? How resulting resolution complexity will compare with 5-tuples being used? From: David Black

[APN-Github]

The “structured attribute” (i.e. the APN Header) is defined in this draft https://datatracker.ietf.org/doc/html/draft-li-apn-header-00#page-3. The APN header option is going to be located in one place in the packet header such as an IPv6 extension header – Hop-by-hop Options header. To resolve this APN header, only one place in the packet header needs to be checked against. While since 5-tuples are located in the various places in the packet header, especially in IPv6 data plane when IPv6 extension headers exist the transport layer information is being pushed further deep, these will make the resolution of the 5 tuples very hard and more complex than that of the APN header.

[APN-Github]

David Black:

Based on discussion of prior issues, if the term "tag" will continue to be used, then the drafts need to be clear that the parameters are not part of the tag – the structure is tag+parameters.

The rest of the response below is clear, although "one place" glosses over what has to be done because the presence of parameters adds complexity. The router/node has to look at not only the tag, but also the parameters in order to figure out what to do – that's the additional complexity. I would suggest taking a hard look at which routers/nodes have to process parameters, in contrast to just using the tag for lookup.

[APN-Github]

Shuping Peng:

Thank you! As we also discussed on the previous issues 13-15, https://mailarchive.ietf.org/arch/msg/apn/kFMAX6airI2sVbzmDZhalV1litE/, we will use APN header which includes APN ID and/or APN Parameters, while the APN ID is mandatory and the APN Parameters are optional as stated in this draft https://datatracker.ietf.org/doc/html/draft-li-apn-header-00#page-3.

You are right that when the APN Parameters are also carried it will bring additional complexity which we’d better carefully look into. We would also like to explore more about the use cases of using the APN Parameters.

So shall we close this issues as well as the issues 13 and 14 based on these discussions? Thank you!

[APN-Github]

Looking at the framework draft (draft-li-apn-framework-04), I did not see any problematic uses of "opaque" or "tag" so I think it's ok to close my issues 13, 14, and 19.

Thanks, --David