Hi Benson, On 24/06/11 5:23 AM, "Benson Schliesser" <[email protected]> wrote:
> Hi, Terry. > > Can you clarify, under what circumstances might a RESERVED prefix be > Routable, or an ALLOCATED prefix be Not Routable? In other words, why is > the Status label not adequate for the PRI concept you've described? The obvious example (and please - I don't care to buy into the brouhaha of 6to4 going historic) is "192.88.99.0/24 reserved for 6to4 Relay Anycast" The designated status is reserved, but it is routable. The current status labels are: RESERVED: designated by the IETF for specific non-unicast purposes as noted. LEGACY: allocated by the central Internet Registry (IR) prior to the Regional Internet Registries (RIRs). This address space is now administered by individual RIRs as noted, including maintenance of WHOIS Directory and reverse DNS records. Assignments from these blocks are distributed globally on a regional basis. ALLOCATED: delegated entirely to specific RIR as indicated. UNALLOCATED: not yet allocated or reserved. It might be in the future, that additional labels are created for events such as RIRs returning address space. To be honest that is me gazing into a broken crystal ball, but seems odd to me to create a matrix (which may grow) for a simple binary choice. The precedent has been set (sort of) in the ipv4 special address registry (http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia l-registry.xml) which has a routable column, so in a way this brings all the other address registries into the 'now'. > > Also, I think the draft should be more specific about what it means to be > "publicly routed". There are cases where RESERVED prefixes get routed > between different Autonomous Systems, and it should be more clear when this > is considered "public" or something else (private?) in the context of your > draft. That's a fair comment. I'll put some words together and push a rev, although off the top of my head 'publicly' is when 2 or more Autonomous Systems do not share a common and unified routing policy except for the announcement and acceptance of routes containing a prefix directly allocated to themselves, or another Autonomous System. But will clarify in a -01 soon. Cheers Terry > > Thanks, > -Benson > > > On 6/22/11 7:46 PM, "Terry Manderson" <[email protected]> wrote: > >> Hi Donald, >> >> Packets following the default route (mis?)configured by the zillions (I >> _never_ exaggerate ;) of operators is not really the concern I have in mind. >> >> To me anyone can announce any prefix, however the expectation that the >> upstream might accept it (thus it becoming routable) is made up of a number >> of decisions. This draft clarifies one aspect of the decision and makes it a >> crystal clear interpretation for BGP security implementations and operators >> alike. >> >> Cheers >> Terry >> >> >> On 23/06/11 7:09 AM, "Smith, Donald" <[email protected]> wrote: >> >>> Given that many packets are routed due to default routes your category of >>> "routable" should probably be announcable. >>> Or are you looking for a mechanism similar to the juniper concept of >>> Martians >>> where they had a set of rfc1918 addresses "default coded" into their system >>> so >>> they couldn't be used or routed unless you modified their Martian filter? >>> >>> >>> >>> When packets collide the controllers cease transmission AND wait a random >>> time >>> before retransmission (mostly)! >>> >>> [email protected] >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>> Terry Manderson >>>> Sent: Tuesday, June 21, 2011 6:40 PM >>>> To: [email protected] >>>> Subject: [GROW] FW: New Version Notification for draft-manderson- >>>> routing-intent-00.txt >>>> >>>> Chairs and WG, >>>> >>>> I seek your feedback on the I-D below. >>>> >>>> I'd also like to present this to the WG in Quebec. >>>> >>>> Cheers >>>> Terry >>>> >>>> >>>> ------ Forwarded Message >>>>> From: <[email protected]> >>>>> Date: Tue, 21 Jun 2011 17:31:50 -0700 >>>>> To: Terry Manderson <[email protected]> >>>>> Cc: Terry Manderson <[email protected]> >>>>> Subject: New Version Notification for draft-manderson-routing-intent- >>>> 00.txt >>>>> >>>>> A new version of I-D, draft-manderson-routing-intent-00.txt has been >>>>> successfully submitted by Terry Manderson and posted to the IETF >>>> repository. >>>>> >>>>> Filename: draft-manderson-routing-intent >>>>> Revision: 00 >>>>> Title: Signalling Public Routing Intent (PRI) for Internet >>>> Protocol >>>>> Addresses in IANA Registries >>>>> Creation date: 2011-06-22 >>>>> WG ID: Individual Submission >>>>> Number of pages: 12 >>>>> >>>>> Abstract: >>>>> This document provides direction to IANA to mark existing and >>>> future >>>>> IANA IPv4 and IPv6 allocations with generic terms pertaining to >>>> the >>>>> Public (global) Routing Intent (PRI). >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>> >>>> ------ End of Forwarded Message >>>> >>>> _______________________________________________ >>>> GROW mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/grow >>> >>> This communication is the property of Qwest and may contain confidential or >>> privileged information. Unauthorized use of this communication is strictly >>> prohibited and may be unlawful. If you have received this communication >>> in error, please immediately notify the sender by reply e-mail and destroy >>> all copies of the communication and any attachments. >> >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
