You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
20. Does APN ID carry a piece of information that is potentially semantically *richer* than the five tuple and making that available to path elements that would not otherwise have that data? From: Ted Hardie
#20
Open
APN-Github opened this issue
Jan 10, 2022
· 2 comments
The path elements that are not aware of APN or do not support APN will not be able to process the APN header since there are no corresponding configurations. The APN ID will only be processed in the nodes that are already enforced with policies against the APN ID.
The text was updated successfully, but these errors were encountered:
Adrian Farrel:
I think this misses the point that Ted was making:
• Could the “APN ID” (I think we should say “APN attribute” per #19) carry more information than is found in the classic five tuple?
o Answer, yes. While some approaches might encode the 5-tuple or hash the 5-tuple into the APN attribute, and others might only carry some of that information, further approaches might put additional information into the APN attribute
• Is that information made available to nodes that would not otherwise have access to that information?
o Answer, yes. That is, before the addition of the APN attribute, nodes in the network only have the fields in the current header. That includes the 5-tuple, but not any additional information that might be added to the APN attribute. After the addition of the APN attribute, nodes on the path of the packet (“path elements” according to Ted) will have access to this information.
o It is true, as you say, that only those nodes on the path that are APN aware will be able to process the information, but that is not Ted’s question. He is trying to work out what information will be exposed to which nodes.
The APN ID is defined here in this draft https://datatracker.ietf.org/doc/html/draft-li-apn-header-00#section-4. The carried information can be obtained based on the configurations at the edge node of the network, which are based on the matching relationship against the 5 tuples and sometimes also the layer 2 information as long as those information are exiting in the packet header.
All the information carried in the packets can be theoretically accessed by the nodes they pass through. Just generally for the nodes that cannot support the feature the carried information will be skipped and not be processed, and even if the nodes try to process they will not be able to perform properly since there are no corresponding configurations in the nodes against the carried information.
The path elements that are not aware of APN or do not support APN will not be able to process the APN header since there are no corresponding configurations. The APN ID will only be processed in the nodes that are already enforced with policies against the APN ID.
The text was updated successfully, but these errors were encountered: