Re: [RADIR] Last Call on problem statement -01

[Thomas Narten <[e-mail]>]

Hi Marla,

Vince, Jason and I had a short call. We chatted about your comments.

Thomas Narten <[e-mail]> writes:

> > 2. Change ISP to Upstream Provider throughout the document.  Add =
> > definition of Upstream Provider.  I suggest this because the term ISP =
> > has become a rat hole in the ARIN region.  I thought to replace it with =
> > LIR, but you can still end up with a rat hole on that as well.  Saying =
> > Upstream Provider makes it clear without dictating a categorical type.  =
> > OR add a definition of ISP to mean Upstream Provider.

> I just went through the document searching for ISP, and I think in
> most cases, the current term ISP is correct, as the term is used
> generically. Indeed, I think using "upstream" would be wrong. (There
> are a few places where adding "upstream" seems like a good
> clarification, but this is mostly in the context of address
> delegations.)

> Thinking a bit more about this, what exactly does the term "Upstream
> Provider" (as you are thinking) mean? Is this just to indicate where
> the address block comes from (i.e., out of an upstream's aggregate),
> or does it mean more than that, e.g., where one gets transit from?

Revised suggestion:

add the following definition:

Internet Service Provider (ISP): an entity that provides Internet
	 connectivity between sites. The term is used loosely in this
	 document to mean any entity that provides connectivity
	 between different organizations. Customers may number their
	 devices out of the ISP's address space, or use address space
	 obtained from elsewhere.

In the following, change "ISP" to "upstream ISP" in a couple of
places.

OLD:
	  <t hangText="Provider Aggregatable (PA) address space:">

	    Address space that an end site obtains from an ISP's
	    address block. The main benefit of PA address space
	
NEW:
	  <t hangText="Provider Aggregatable (PA) address space:">

	    Address space that an end site obtains from an upstream
	    ISP's address block. The main benefit of PA address space



OLD:
      <section title="Traffic Engineering">
	<t>
	  The mechanisms used to achieve multihoming and inbound
	  Traffic Engineering are the same. In both cases, a specific
	  prefix is advertised into the routing system to "catch"
	  traffic and route it over a different path than it would
	  otherwise be carried. When multihoming, the specific prefix
	  is one that differs from that of its ISP or is a
	  more-specific of the ISP's PA. Traffic Engineering is

NEW:
      <section title="Traffic Engineering">
	<t>
	  The mechanisms used to achieve multihoming and inbound
	  Traffic Engineering are the same. In both cases, a specific
	  prefix is advertised into the routing system to "catch"
	  traffic and route it over a different path than it would
	  otherwise be carried. When multihoming, the specific prefix
	  is one that differs from that of its upstream ISP or is a
	  more-specific of the ISP's PA. Traffic Engineering is

	  
> > 3. Shouldn't 4.3 have a caveat "renumbering can be painful if NAT is not =
> > utilized"?  This paragraph makes its sound like everyone finds =
> > renumbering painful...when they don't.

> I agree that something about this needs to be added.

> Hmm. I'm somewhat surprised to note that NAT isn't even used in the
> document!

> I wonder if we then need to add a section (somehow) that points out
> that NAT avoids renumbering pain, but then also list some of the
> standard reasons why NAT is not recommended as the solution to our
> "problem".

I think we are collectively nervous about mentioning NAT. It could be
quite a challenge to mention it without adding a lot of text and we'd
risk getting sucked into the big "NAT is evil," "is not" rathole.

Can you suggest some text?

Thomas


_______________________________________________
RADIR mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/radir