[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSIS] Re: [Int-area] RAO for IPv4
I've got an architectural issue with any protocol having specific
values in the RAO. In general, that's
a poor approach, as it will (in the long term) lead to multiple
protocols piggybacking on RAO. Why not simply allocate another
option on a per-protocol basis?
This also has the nice side effect that it ensures that things are
backward compatible.
Tony
On Oct 24, 2007, at 12:56 PM, Jukka MJ Manner wrote:
Hi Thomas, Bob,
Thanks for the discussion.
The specific application that needs (well, to be precise, would
greatly
benefit) RAO is NSIS. That is why NSIS ML is CC:d.
Moreover, the RSVP spec talks about multiple RAO values, but lets
it open
as to whether IPv4 should also have those, not just IPv6.
RFC2113 also says that "The semantics of other values in the Value
field
are for further study."
The point is, is it time to study those "other values" further? At
least
GIST and the whole NSIS framework would greatly benefit from more
values
than just "0" for IPv4, and these values should be the same for
IPv6 also,
for simplified implementations.
There is a lot of discussions about RAO in the GIST spec, e.g.,
Sections
4.3.1., 4.3.4., 5.3.2.1., 5.3.2.2., 6. IANA Considerations and
Appendix C:
http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp/
Regards,
Jukka
On Wed, 24 Oct 2007, Thomas Narten wrote:
Bob Hinden and I had some further offlist discussion about this.
My understanding is that the IPv4 RA option is very basic. It says
"look at this packet". The option itself doesn't contain any
additional information or "hint" as to what to look for or what the
packet contains.
The semantics of the IPv6 router alert option are different. The
value
itself is used to coved: from [171.70.245.121] ([171.70.245.121]) by
xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 24 Oct 2007 14:11:55 -0700
In-Reply-To: <Pine.LNX.4.64.0710242242440.27265 at sbz-31.cs.Helsinki.FI>
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>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E at cisco.com>
Content-Transfer-Encoding: 7bit
From: Tony Li <tli at cisco.com>
Date: Wed, 24 Oct 2007 14:11:44 -0700
To: Jukka MJ Manner <jmanner at cs.Helsinki.FI>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 24 Oct 2007 21:11:55.0563 (UTC)
FILETIME=[8194C7B0:01C81682]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3090; t=1193260317;
x=1194124317; c=relaxed/simple; s=sjdkim3002;
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=vkthdi+u2wwYAcV1K+1pMK9RTw8RVK28glMFkvtD9Uw=;
b=B6HHfVQRXysTSOQldCHVKOMdrspiHJlBezQtR+q2iOUdGAfrkCw217JltHn+gcqFNBr1Ssh2
U3Y7yhL6ipYTFEo4ECz1AM2/e2bVtEEXytl/1q1G9V2VuDtq0uEY07Qh;
Authentication-Results: sj-dkim-3; header.From=tli at cisco.com; dkim=pass (sig
from cisco.com/sjdkim3002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
X-Mailman-Approved-At: Wed, 24 Oct 2007 20:07:17 -0400
Cc: Thomas Narten <narten at us.ibm.com>, int-area at lists.ietf.org,
NSIS Working Group <nsis at 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
I've got an architectural issue with any protocol having specific
values in the RAO. In general, that's
a poor approach, as it will (in the long term) lead to multiple
protocols piggybacking on RAO. Why not simply allocate another
option on a per-protocol basis?
This also has the nice side effect that it ensures that things are
backward compatible.
Tony
On Oct 24, 2007, at 12:56 PM, Jukka MJ Manner wrote:
Hi Thomas, Bob,
Thanks for the discussion.
The specific application that needs (well, to be precise, would
greatly
benefit) RAO is NSIS. That is why NSIS ML is CC:d.
Moreover, the RSVP spec talks about multiple RAO values, but lets
it open
as to whether IPv4 should also have those, not just IPv6.
RFC2113 also says that "The semantics of other values in the Value
field
are for further study."
The point is, is it time to study those "other values" further? At
least
GIST and the whole NSIS framework would greatly benefit from more
values
than just "0" for IPv4, and these values should be the same for
IPv6 also,
for simplified implementations.
There is a lot of discussions about RAO in the GIST spec, e.g.,
Sections
4.3.1., 4.3.4., 5.3.2.1., 5.3.2.2., 6. IANA Considerations and
Appendix C:
http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp/
Regards,
Jukka
On Wed, 24 Oct 2007, Thomas Narten wrote:
Bob Hinden and I had some further offlist discussion about this.
My understanding is that the IPv4 RA option is very basic. It says
"look at this packet". The option itself doesn't contain any
additional information or "hint" as to what to look for or what the
packet contains.
The semantics of the IPv6 router alert option are different. The
value
itself is used to convey additional "hints" about processing.
My sense is that the semantics of the IPv4 and IPv6 Router Alert
option are sufficiently different that sharing the name space just
doesn't make any sense.
That is, the ID says:
This document proposes the creation of a new IANA registry for
managing IPv4 Router Alert Option Values. In conjunction with
this, it also proposes an update to the way in which IPv6 Router
Alert Option Values are assigned in the existing IANA registry.
But there are no defined IPv4 Router Alert Option values (other than
zero), and it would be inappropriate to change the semantics of any
existing usages (too late for that) and it would also be
inappropriate
to consider doing this in the absense of a specific new application
that would make use of a new value. This document does not propose
such a new usage.
Hence, at this point, I'm opposed to the actions called for in the
document.
Thomas
_______________________________________________
Int-area mailing list
Int-area at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis
nvey additional "hints" about processing.
My sense is that the semantics of the IPv4 and IPv6 Router Alert
option are sufficiently different that sharing the name space just
doesn't make any sense.
That is, the ID says:
This document proposes the creation of a new IANA registry for
managing IPv4 Router Alert Option Values. In conjunction with
this, it also proposes an update to the way in which IPv6 Router
Alert Option Values are assigned in the existing IANA registry.
But there are no defined IPv4 Router Alert Option values (other than
zero), and it would be inappropriate to change the semantics of any
existing usages (too late for that) and it would also be
inappropriate
to consider doing this in the absense of a specific new application
that would make use of a new value. This document does not propose
such a new usage.
Hence, at this point, I'm opposed to the actions called for in the
document.
Thomas
_______________________________________________
Int-area mailing list
Int-area at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis