Subject: Re: [GROW] FW: New Version Notification for draft-manderson-routing-intent-00.txt

From: Terry Manderson <[email-masked]>
Date: Wed, 22 Jun 2011 17:46:51 -0700

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-masked]> 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-masked]
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Terry Manderson
>> Sent: Tuesday, June 21, 2011 6:40 PM
>> To: [email-masked]
>> 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-masked]>
>>> Date: Tue, 21 Jun 2011 17:31:50 -0700
>>> To: Terry Manderson <[email-masked]>
>>> Cc: Terry Manderson <[email-masked]>
>>> 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-masked]
>> 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.

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 23 Jun 2011 14:23:57 -0500

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?

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.

Thanks,
-Benson

---

From: Terry Manderson <[email-masked]>
Date: Thu, 23 Jun 2011 16:54:53 -0700

Hi Benson,

> 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'.

> is considered "public" or something else (private?) in the context of your

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

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 23 Jun 2011 19:27:20 -0500

> The designated status is reserved, but it is routable.

Thanks for the clarification, Terry.  Your explanation makes sense.

Out of curiosity:  In the event that an RIR sets aside a block to be Non
Routable (such as ARIN Draft Policy 2011-5) would the PRI designation be
ALLOCATED Non Routable, or something else?

Cheers,
-Benson

---

From: Terry Manderson <[email-masked]>
Date: Thu, 23 Jun 2011 21:25:29 -0700

> Thanks for the clarification, Terry.  Your explanation makes sense.

:-)

> ALLOCATED Non Routable, or something else?

I'm not familiar with the ARIN Draft Policy 2011-5 - let me read and I will
respond after the weekend.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Tue, 28 Jun 2011 17:32:04 -0700

Hi Benson,

Not speaking to the utility of that particular proposal, but I would think
that the policy (ARIN Draft Policy 2011-5) might also need to be reposted as
an IETF RFC to modify the IANA address registry. (in much the same way
rfc3849 came from the APNIC allocation)

If that were the case then the IANA address registry would reflect it.

Otherwise, I am not aware of any provision for an individual RIR to set a
particular prefix's status without some global policy work being done.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Tue, 28 Jun 2011 21:15:54 -0700

A new version (-01) has been posted based on WG feedback.

Please read and review.

I would also like to ask the Chairs if this document could be adopted as a
GROW WG item given no WG meeting will occur in Quebec, and I will (sadly)
miss the opportunity to present the draft there.

Cheers
Terry

> New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>         Title           : Signaling Public Routing Intent (PRI) for Internet
> Protocol Addresses in IANA Registries
>         Author(s)       : Terry Manderson
>         Filename        : draft-manderson-routing-intent-01.txt
>         Pages           : 12
>         Date            : 2011-06-28
> 
>    This document provides direction to IANA to mark existing and future
>    IANA IPv4 and IPv6 allocations with generic terms pertaining to the
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-manderson-routing-intent-01.txt

---

From: Arturo Servin <[email-masked]>
Date: Wed, 29 Jun 2011 08:52:53 -0300

Benson,

	I agree with Terry.

	When the proposal was sent to the IETF the environment was different. We still have v4 addresses in IANA's pool and I think that the feeling was "we do not want to give that precious space for a shared pool because there is one already". Now things are different, there are no more addresses in the central pool, v4 address are more scarce, ISPs claim that need space for transition technologies to v6, and the ARIN community is willing to give some space for that purpose (this last one is the important one IMHO).

	I cannot speak for others, but in my view a new I+D similar to the last one (I think it was sent to OPSWAG WG) with some amendments would have more opportunities to be adopted.

Regards,
.as