Hi Roger,
At 21:46 10-01-2013, Roger Jørgensen wrote:
I agree, in practice this happen too often, which is why I suggest
this feature should be labeled EXPERIMENTAL but stable, or something
similiar and explain why.
That can also hurt deployment so we have to be very very clear on what
we mean with EXPERIMENTAL here.
There was an provider in the Far East leaking out
IPv4 shared address space and there was a
provider in the Far West who did not follow the
guidance in the specification. My guess is that
the label will be ignored. In the IETF even if
you are very very clear on what you mean someone
will find a way around that. :-)
In the beggining only a limited piece of that reserved /12 will be
used, if we divide it into regions or not that's no big deal, point
being it's limited affect on the _global_ routing table since those
/32 will have to be announced there. I mention RIR regions to get some
geographical diversity in the experiment, not being EU/US region
alone.
And about handing out those /32, there will be a set of guidelines
telling the RIR/entinty managing this in practice on how they should
deal with it, in all practical matter the LISP-EID-wg will have to
decide on which ISP should be let into the experiment now in the
begging to make sure we actual get an experiment.
As a side note, I asked for somebody to point me
to the IANA policy mentioned in the draft (or
during previous discussions). Nobody did
that. A long time ago this would be a matter of
"please reserve a /12" without any hassle. Let's
say LISP is successful. There will be a time
when that /12 is not enough. Then what?
I don't think that it is a good idea for the IETF
to get into RIR policy in a draft. The only
reason to call all this an experiment (even
though it is actually an experiment) is to get
the IPv6 address space for free. I don't think
that there would be many hurdles in getting that
if someone puts effort into it. A simple path is to say so and ask nicely. :-)
Regards,
-sm
P.S. The LISP WG did ask nicely. Maybe there
wasn't a thorough discussion of the issues.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
