Re: RAO for IPv4

Hi Roland,

> 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


Thanks for the reference.  I'm afraid that I don't agree with all of the
rationale presented there.


> 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.


I'm fine with reusing RAO.  That is in fact exactly what it's there  
for.  However,
RSVP does not attempt to piggyback any data into RAO.  That's where
you're diverging from the previous model and exactly where I have an
issue.


> 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.


The whole point of RAO is to take the packet out of the fast path,
regardless of the value.  An NSIS implementation could, if it was
carefully and specifically constructed to do so, have a fast path
that did understand the signaling protocol and passed uninteresting
versions in the fast path.  There's no reason that this could not
be done with an option independent of RAO.


> 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.


This results in GIST using RAO as a transport, which is simply
a layering violation.  Again, there's no reason to not allocate a  
separate
option for carrying this value.  Please consider the case of
GISTv2.  What do you?  Allocate more RAO values?  What happens if
there's some other subsequent protocol that wants hop-by-hop
visibility.  Do you allocate bits for that protocol from RAO as well?
Suppose that it needs to co-exist with GIST.  Do you allocate code
points for the cross product of the two protocol code points?  What
happens if there's a third protocol?


> 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?


I'm suggesting another IP option that has semantics independent
from RAO that would be wholly used for GIST.

Tony