Hi Tony, Tony Li wrote: > Thanks for the reference. I'm afraid that I don't agree with all of the > rationale presented there.
Oops, good to hear another opinion. > 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. Ok. You are referring to the fact that the NSLP-ID is somehow mapped to the RAO value. Probably that's new, because RSVP is only one signaling application whereas GIST was designed to support different signaling applications like QoS-NSLP and NAT/FW-NSLP. > 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. There is no need that the fast path understands the signaling protocol. It simply takes only those packets out of the fast path that have a particular matching set of RAO values, and ideally packets with other RAO values are simply forwarded without leaving the fast path. This is especially useful for aggregation techniques (e.g., RFC 3175). However, if you think about inter-domain aggregation RAO values do not help much and that's where using a new option could be interesting indeed. So I guess you are correct: conceptually the RAO values are shared between different applications depending on such a functionality. Currently, that would be: RSVP + RSVP Aggregation, GIST per NSLP + Aggregation for QoS NSLP. We discussed RAO things also last year at IETF-67: see http://www3.ietf.org/proceedings/06nov/slides/nsis-1/sld13.htm and http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt One conclusion was that some existing implementations for RAO are definitely broken, but should be fixed for RSVP anyway. Problem with Firewalls are always expected, too. > 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? These are indeed good questions. For NSLP versions: I vaguely remember discussing last year on the NSIS list that different NSLP versions must be demultiplexed within the NSLP itself and we do not consider to allocated a NSLP-ID per version. > I'm suggesting another IP option that has semantics independent > from RAO that would be wholly used for GIST. Ok. This would probably make chances smaller that GIST packets pass firewalls or NATs. However, GIST will not work very well through NATs without special NAT support anyway, so the new option should be implemented together with GIST support in these boxes. But legacy middleboxes may break the connectivity for GIST then. What do others think? Regards, Roland _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
