ok, I'll bite:
> -----Original Message-----
> From: Scott Brim [mailto:[EMAIL PROTECTED]
> Sent: 25 October 2007 14:17
> To: Tony Li
> Cc: Roland Bless; Jukka MJ Manner; NSIS Working Group;
> [email protected]
> Subject: [NSIS] Re: [Int-area] 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.
That appendix was an attempt to capture quite intense discussions
between
the authors, routing area reviewer, and our chairs and ADs. Quite
possibly
there are things which are not ideal about it - if you have concerns I'd
be keen to understand them (might be easier not to influct that on the
mailing lists in the first instance, however).
> >
> >
> > > 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.
I don't believe either RSVP or NSIS or any other protocol is
piggybacking
data in the RAO, either for v4 or v6. (Except possibly in the case of
RSVP aggregation, see below.)
> >
> >
> > > 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.
That is currently the case for v4. That is not the case for v6, at
least, not according to my reading of paragraph 2 of section 2.2 of
rfc2711:
" Routers that recognize the option will examine datagrams carrying it
more closely to determine whether or not further processing is
necessary. The router only needs to parse the packet in sufficient
detail to decide whether the packet contains something of interest.
The value field can be used by an implementation to speed processing
of the datagram within the transit router."
So, the question on the table is whether that ability (to speed
processing
by looking at the value field) would be useful in the v4 case or whether
for some reason it could only ever be useful for the IPv6 case.
> > 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.
See below on the question of a separate option.
> >
> >
> > > 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.
I'm afraid that when we are talking about relying on packet interception
in the forwarding layer to pass data to a signalling protocol handler,
the layering model is already being molested. But I agree that there
can be layering concerns. Let me consider the v6 case again, for
which there are (at least) two RAO values assigned, rsvp and mld. There
are two ways to interpret the usage of RAO-carrying packets:
1) The router logic is:
- if the packet carries RAO value = 0 it is an ICMPv6 message (IP proto
58)
with type field 130/131/132: therefore, pass it to the MLD process;
- if the packet carries RAO value = 1 it is an RSVP message (IP proto
46)
with RSVP Msg Type = 1
- otherwise forward the packet
2) The router logic is:
- I want to intercept RSVP path messages, so pick packets with RAO
value=1
out of the forwarding path and examine them more closely
- I want to intercept MLD messages, so pick packets with RAO value=0 out
of the forwarding path and examine them more closely
(1) certainly feels like a layering violation, and I think (2) is more
architecturally sound; however, the end result is pretty much the same:
RAO values are associated with specific protocols, or sub-protocols of
protocols. And RAO values for IPv6 can be associated with subprotocols
of NSIS in exactly the same way. If this is moral for IPv6 why can it
not
be for IPv4? (I'm well aware of the fact that RAO per se is much more
important for v4 than v6 because of header chain processing issues;
however,
the ability to differentiate between different RAO users in the RAO
itself
would seem similar.)
As an aside, rfc3175 really would seem to involve a layering violation,
since the aggregation level, which is very semantically signficant for
the
RSVP processing, is carried *only* in the RAO value field and not the
RSVP messages itself. But it may be that I've misunderstood this aspect
of 3175.
> > 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?
There will certainly be an art to allocating new RAO values. That
problem
already exists for IPv6, although the IANA considerations section of
2711
is (by today's standards) somewhat brief. That does not per se show that
the concept is not valid (but see further below).
> >
> >
> > > 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.
OK: I was initially very confused by this suggestion, because you would
end up with the 'do I look at this more closely?' check on the fast path
being something like
IF (rao-present OR (new-option-present AND value in
{interesting_values}))
rather than
IF (rao-present AND value in {interesting_values})
which certainly *looks* simpler. And in the first case, packets with
new-option
would be forced onto the slow path in all existing routers, whereas in
the
second, marked packets could still be forwarded on the fast path in
routers
not interested in the signalling. So while a new option is certainly
possible
(logically), I don't understand the backwards compatibility advantages.
However, it may be the case that the current facts of life are that in
reality,
the presence of options in IPv4 packets will just be ignored; in that
case,
defining a new option might be a cleaner approach. It still seems weird
to me
that the approach to replicate IPv6 RAO functionality in IPv4 is not to
extend
the IPv4 RAO spec but to introduce a new option, but backwards
compatibility
does lead to this sort of oddity (and far worse, of course).
Bottom line:
- IPv6 RAO value filtering functionality appears to be useful. If
actually the
modern consensus is that it is overspecified and a simpler (possibly
less
optimised for certain scenarios) approach is architecturally and
practically
better, then that is a fair view. We can forget the question for IPv4
and
use a single value for IPv6; the consequence is that all nodes that
process
any signalling messages will have to process all signalling messages off
the
fast path.
- If it is still the view that value-based filtering is useful for IPv6,
there
may still be a view that it is not useful for IPv4. However, I haven't
seen
that argument.
- If value-based filtering is useful for IPv4, you can either achieve it
by
extending rfc2113 or defining a new option for IPv4. And we can then
work out
the pros and cons of those approaches.
thanks for reading,
robert h.
> >
> > Tony
> >
> >
> > _______________________________________________
> > Int-area mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/int-area
>
>
> _______________________________________________
> nsis mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/nsis
>
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
