Hi Adrian, Thank you. I added more explanations below.
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. Best Regards, Shuping From: Apn [mailto:[email protected]] On Behalf Of Adrian Farrel Sent: Tuesday, January 11, 2022 5:10 AM To: 'Pengshuping (Peng Shuping)' <[email protected]>; 'apn' <[email protected]> Cc: [email protected]; [email protected]; 'Black, David' <[email protected]>; [email protected] Subject: Re: [Apn] Issues to be closed #19-#21 Hi Shuping, I've been following along with your resolution of issues and have been in agreement with most, but... > 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 > https://github.com/APN-Community/Issues/issues/20 > > 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. 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. Best, Adrian
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
