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
