A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing Working Group of
the IETF.
Title : Manifests for the Resource Public Key Infrastructure
Author(s) : Rob Austein
The IESG has approved the following document:
- 'An Infrastructure to Support Secure Internet Routing'
(draft-ietf-sidr-arch-13.txt) as an Informational RFC
This document is the product of the Secure Inter-Domain Routing Working
Group.
The IESG contact persons are Stewart Bryant and Adrian
On Apr 30, 2011, at 11:14 PM, Randy Bush wrote:
Most of the messages in the protocol are nice and small messages, but
the error-report message can be of arbitrary size since it can have
trailing diagnostic text...
Can we specify a maximum value for length of this message? A cache
Not to mention the fact that IPv6 is going to have a significant contribution.
Tony
I think you are saying (extending Tom's observation) that the transition to a
FIB scalability solution possibly should happen sooner due to IPv6 growth
(as compared to that based on IPv4 growth considerations
Not at all. What I'm trying to say is that the IPv6 RIB is already growing at
about 60% y/y. Further, the transition to IPv6 _may_ trigger de-aggregation
within the IPv4 RIB, as we maximize the utilization of the v4 address space.
Given these two factors, I'm highly skeptical of a 15% growth
Not at all. What I'm trying to say is that the IPv6 RIB is already
growing at about 60% y/y. Further, the transition to IPv6 _may_
trigger de-aggregation within the IPv4 RIB, as we maximize the
utilization of the v4 address space.
Given these two factors, I'm highly skeptical of a 15%
On Tue, May 31, 2011 at 1:29 PM, Randy Bush ra...@psg.com wrote:
Not at all. What I'm trying to say is that the IPv6 RIB is already
growing at about 60% y/y. Further, the transition to IPv6 _may_
trigger de-aggregation within the IPv4 RIB, as we maximize the
utilization of the v4 address
- Original Message -
From: Sriram, Kotikalapudi kotikalapudi.sri...@nist.gov
To: t.petch ie...@btconnect.com; sidr@ietf.org
Sent: Friday, May 27, 2011 7:58 PM
Tom,
Thanks for your comment.
We have preliminary results that extend the RIB estimation (with BGPSEC) to
LISP (or, similar
sriram was working on the effects of bgpsec on the growth rate, not
every other game being played in town. give the man a break.
to be fair to both parties... the excel can be adjusted if you so
desire.
true. and we could play with it to try to model lots of causes. point
taken.
randy
On May 27, 2011, at 11:50 AM, t.petch wrote:
RRG, before looking for some architectures that would solve the world's
routing
problems, did discuss the expected capacity of DFZ routers, given the
expected
rate of growth of technology, so as to work out how long the IETF has got to
come up
On 5/31/2011 10:52 AM, Paul Hoffman wrote:
On May 31, 2011, at 10:23 AM, Randy Bush wrote:
1. Maybe add to section 5.9 An Error Report PDU MUST NOT be sent for
an Error Report PDU..
makes sense
To answer the initial request, it seems reasonable to specify the
length of the Arbitrary Text
Tue, May 31, 2011 at 10:52:07AM -0700, Paul Hoffman:
C or assembly-based implementations will need to malloc (etc.) the buffer for
the incoming message. Having that fit into 256 octets could easily have some
value to some implementations.
that magic could just as easily be 64 or 512 octets
On 5/31/2011 11:19 AM, Hannes Gredler wrote:
On Tue, May 31, 2011 at 10:56:52AM -0700, Joe Touch wrote:
|
|
| On 5/31/2011 10:52 AM, Paul Hoffman wrote:
|On May 31, 2011, at 10:23 AM, Randy Bush wrote:
|
|1. Maybe add to section 5.9 An Error Report PDU MUST NOT be sent for
|an Error Report
wonder what the normative procedure is for too-large messages ?
anything over 246.34 octets should have every other nibble removed,
then repacked, and the procedure repeated until it is under 246.34
octets.
i'll get that into the next draft.
can we please keep the idr out of sidr?
randy
On Tue, May 31, 2011 at 1:44 PM, Randy Bush ra...@psg.com wrote:
sriram was working on the effects of bgpsec on the growth rate, not
every other game being played in town. give the man a break.
to be fair to both parties... the excel can be adjusted if you so
desire.
true. and we could
15 matches
Mail list logo
