Re: [Int-area] RAO for IPv4

Hi Tony,

Tony Li wrote:
> I've got an architectural issue with any protocol having specific values
> in the RAO.  In general, that's
> a poor approach, as it will (in the long term) lead to multiple
> protocols piggybacking on RAO.  Why not simply allocate another option
> on a per-protocol basis?
> 
> This also has the nice side effect that it ensures that things are
> backward compatible.

Thanks for your comments. If you're interested in this topic
I'd like to point at Appendix C of the GIST draft that provides
more background information:
http://tools.ietf.org/html/draft-ietf-nsis-ntlp-14#appendix-C

We had already some discussions about this and I'll
try to summarize why we choose to use the RAO (maybe other NSIS WG
members or Robert can jump in here) approach.
It was mainly driven by RSVP experience:
1) better chances of NAT and Firewall traversal, an own protocol
   number didn't work too well for RSVP (raw IP with protocol #46)
2) RSVP already used the RAO mechanism, thus lets re-use it.

The basic concept is: due to path-coupled signaling
we want to intercept signaling packets that are sent to
the data flow's destination.
Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW NSLP)
uses a specific RAO value, so a packet can bypass easily
if it carries the "wrong" RAO value. This assumes that
an implementation can specifically intercept packets
depending on the RAO value and let non-matching packets
bypass in the fast path.

I don't see the danger that "multiple protocols are piggybacking
on RAO", because only protocols will use this mechanism if
they need to _intercept_ packets, like GIST does for discovering
signaling nodes along a flow's path.
I don't understand what you mean by "allocate another option on a
per-protocol basis". Do you mean an own protocol number or a new IP
option or demultiplexing within the protocol itself (which we also do).
Could you explain this a little bit more?

Regards,
 Roland