Re: RAO for IPv4

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