Re: [Apn] Issues to be closed #19-#21

[Adrian Farrel <[e-mail]>]

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