[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSIS] Re: [Int-area] RAO for IPv4
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 From nsis-bounces at ietf.org Wed Oct 24 20:08:22 2007
Return-path: <nsis-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1IkqFp-0001PM-Q7; Wed, 24 Oct 2007 20:07:17 -0400
Received: from nsis by megatron.ietf.org with local (Exim 4.43)
id 1Ikpp9-00067P-CI
for nsis-confirm+ok at megatron.ietf.org; Wed, 24 Oct 2007 19:39:43 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikpp9-000673-1E
for nsis at ietf.org; Wed, 24 Oct 2007 19:39:43 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
helo=sj-iport-3.cisco.com)
by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikpp8-00055b-Ga
for nsis at ietf.org; Wed, 24 Oct 2007 19:39:42 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
by sj-iport-3.cisco.com with ESMTP; 24 Oct 2007 16:39:42 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9ONdf3L031721;
Wed, 24 Oct 2007 16:39:41 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
[171.70.151.144])
by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9ONddj1005262;
Wed, 24 Oct 2007 23:39:41 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 24 Oct 2007 16:39:39 -0700
Received: from [171.70.246.92] ([171.70.246.92]) by xfe-sjc-211.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 24 Oct 2007 16:39:39 -0700
In-Reply-To: <471FC70E.4010405 at tm.uka.de>
References: <Pine.LNX.4.64.0710111453460.26919 at sbz-31.cs.Helsinki.FI> <200710111233.l9BCXhrU011347 at localhost.localdomain> <200710241431.l9OEVqIO030663 at cichlid.raleigh.ibm.com> <Pine.LNX.4.64.0710242242440.27265 at sbz-31.cs.Helsinki.FI>
<67DBA10E-1363-4C73-ABB8-0CF3BF739C1E at cisco.com>
<471FC70E.4010405 at tm.uka.de>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0C9555DB-F6F9-4A3F-A379-31E68F5B585F at cisco.com>
Content-Transfer-Encoding: 7bit
From: Tony Li <tli at cisco.com>
Date: Wed, 24 Oct 2007 16:39:28 -0700
To: Roland Bless <bless at tm.uka.de>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 24 Oct 2007 23:39:39.0016 (UTC)
FILETIME=[249C6080:01C81697]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2944; t=1193269181;
x=1194133181; c=relaxed/simple; s=sjdkim1004;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=tli at cisco.com;
z=From:=20Tony=20Li=20<tli at cisco.com>
|Subject:=20Re=3A=20[Int-area]=20RAO=20for=20IPv4 |Sender:=20;
bh=/bt2iEbFlWJvnY0ZBbQJmU4eWIwQVrgqwwvYptSJeSw=;
b=SSQwifu0HVzLSm+h9QvQlgr9DVklNH+HgPqYfIcsj0o+MLgXwS3p3aneF+clLzH+6eRsj8bl
OC4CdgaENimyXFq9qUiVBfkZF65N39V0tQNZ6WuK2x0SqTgoyv+0mDzE0Wsxwb5QoySTenaPZS
IDWKaseW6DV2K9hcNZujfY1Sk=;
Authentication-Results: sj-dkim-1; header.From=tli at cisco.com; dkim=pass (sig
from cisco.com/sjdkim1004 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
X-Mailman-Approved-At: Wed, 24 Oct 2007 20:07:17 -0400
Cc: Jukka MJ Manner <jmanner at cs.Helsinki.FI>,
NSIS Working Group <nsis at ietf.org>, int-area at lists.ietf.org
Subject: [NSIS] Re: [Int-area] RAO for IPv4
X-BeenThere: nsis at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>,
<mailto:nsis-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis at ietf.org>
List-Help: <mailto:nsis-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>,
<mailto:nsis-request at ietf.org?subject=subscribe>
Errors-To: nsis-bounces at ietf.org
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
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis