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
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
