[6bone] Re: RFC 2772 input from RIR space holder

[Petr Baudis]

Dear diary, on Wed, Nov 20, 2002 at 07:39:01PM CET, I got a letter,
where "Jorgensen, Roger" <RJorgensen@upctechnology.com> told me, that...
> Hi,

  Hello,

  after some internal XS26 survey, Jan Oravec proposed another, potentially
much simpler way, how to solve current situation for RIRs. I had some heavy
discussion with Roger about this, but I decided to summarize the main points on
the mailing list as well.

> to keep it simple:
> * 6bone sites can announce each other their pTLA route within the
>   3ffe::/16 cloud including _one_ default 2001::/16 route.
> 
> Then we need a extra addon to this to avoid causing never ending loops:
> * A site can ONLY announce the default RIR prefix to other peers
>   IF they have the more specific RIR prefixes in their table.
> 
> 
> example, I'm a pTLA with no connection to RIR space and should have no RIR
> prefixes in my table, in this cause I can NOT provide transit to RIR 
> space to anyone else than my endusers. Or in other word, I can not provide 
> RIR space transit to other 6bone sites....
> 
> 
> The advantage of this:
> - 6bone/RIR space will become two separate network that can NOT break
>   each other, we (RIR) can guaranty routing easier.
> - 6bone can do as much experimental stuff as they want to, they can still
>   NOT harm production traffic (production traffic should anyway ALWAYS
>   go over and use RIR space)
> 
> disadvantage:
> - it add a bit more complexity to the routing but think what we gain
>   from it are more important.
> - longer routing in general when you're going RIR <> 6bone space.
> 
> 
> It basically give us the chance to make a quality production IPv6 
> network AND still be able to do experimental stuff on 6bone without 
> impact on each other. it also give us (RIR) the chance to guaranty 
> routing in RIR space, or to say it as manager:
> 
> "we can provide production quality on our IPv6 network"
> 
> 
> thoughts?

  Basically, Jan's proposal is like: the distribution of the prefixes does not
need to change fundamentally, the only change required is in 6bone -> RIRs
connections. In such passages, 6bone sites MUST NOT announce prefix 2001::/16
nor any more specific prefixes matching this prefix, and RIR sites MUST filter
any such prefixes.

  The advantages of this:

  + 6bone/RIR space will become two separate networks that can NOT break each
other, RIR people can guarantee routing easier.

  + 6bone can do as much experimental stuff as they want to, they can still
NOT harm production traffic (production traffic should always ALWAYS go over
and use RIR space).

  + Whole 6bone still gets full RIR prefixes feed (with the original proposal,
each pTLA wouild need to have at least one full-transit peering with some sTLA
or direct peering with another pTLA which would have it; this would possibly
lead to further degenration of the 6bone hiearchy).

  + The only really required steps are on the RIR side, and the filtering is
much less complex; Roger says that RIRs can coordinate themselves, so we can
probably take as a working invariant that all RIRs will employ this filtering.

  + The routing prolonging is not so distinct.

  The disadvantages:

  0 In some cases, the routing can still take a little longer path than now; we
can assume that the path will be more stable in many cases, though; we won't be
able to do better anyway.

  ? Roger says that they won't have their prefix "under control", but I fail to
see how it matters, if it won't harm their production RIR-RIR routing anymore.

  ? Roger says that they still won't be able to assure that 6bone sites will
receive their prefix correctly; I fail to see a difference from his solution
here, though; with his solution, additionally, the 6bone site's pTLA would have
to do additional excessive special steps in order to just _receive_ the prefix.

  What are your proposals, opinions, thoughts, votes and so on?

  (Note that I believe that it is certainly not desirable to turn this thread
into another flamewar about details, professionality, "productionness" of
networks and so on. Please desist from such things, and if someone else (with
both some specific people and general audience in mind) won't, it would be
probably nice not to prolong such flames and thus not to reply to such emails.)

  Kind regards,

-- 
 
				Petr "Pasky" Baudis
.
weapon, n.:
        An index of the lack of development of a culture.
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/