I have not paid attention to NSIS recently but architecturally I find Tony's arguments to be very persuasive.
swb On 24 Oct 2007 at 16:39 -0700, Tony Li allegedly wrote: > > 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 _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
