On 8/31/12 4:30 AM, Luigi Iannone wrote:
Hi Brian,
thank you for the review. Few comments inline.
On 30 Aug. 2012, at 15:31 , Brian Haberman <[email protected]>
wrote:
Ok, so I typed too soon...
On 8/30/12 9:00 AM, Brian Haberman wrote:
All, As a part of the publication process, I have completed my
initial review of draft-ietf-lisp-eid-block. The draft is
well-written and concise and I thank you for that.
The only suggestion I would make for this document is to drop
the use of the 2119 language. It is only used in a few places
and those uses are not really appropriate for 2119 language. I
would suggest re-writing those guidelines with normal prose and
drop the 2119 boilerplate from the document.
We tried not to use so much the 2119 language, but if you think it is
better to drop it completely, this can be done.
Given the places it is used and the goal of this document, I don't see
the need for 2119 language.
But, what do you think about section 8 "Routing Consideration" ?
There, with 2119 language, we recommend that routers that do not
support LISP do not handle the prefix in any special way. WOuldn't be
better to maintain that part?
Not really, for two reasons. One, this type of guidance is trying to
tell operators how to run their networks. The IETF has a very poor
track record of doing that and I can assure you that such direction will
raise a few ADs eyebrows. Second, any guidance harvested from this
section by equipment vendors does not need 2119 keywords. Those terms
are not meant to dictate implementations, they are for interoperability.
This draft would benefit from the addition of enhanced text on why
a /16 is needed. What prefix lengths are expected to be allocated
to end-sites?
IMHO, this is something that should not be discussed in the document.
Prefix length allocation will be based on operational reasons and
allocation policies that may change in time.
I disagree. There needs to be some justification for why the particular
request is being made. For example, 6to4 is allocated an IPv6 prefix
and its RFC (3056) describes why its particular prefix size is needed.
Moreover, this request is wading into a new area. It is asking for a
block of addresses from IANA which will then be sub-delegated to end
networks. Who will manage these allocations? Using what guidelines?
And given the statements in section 8 about these EIDs being routed
natively, are you treading into the RIR space? I will have to discuss
with my fellow ADs what their understanding was with respect to the
routability of EIDs during the LISP rechartering.
How many networks are expected to participate in this experiment?
Very difficult to say, participants are steadily growing. But let's
have a long term viewpoint, if the LISP "experiment" is successful
and widely adopted wouldn't be better if the reserved prefix does not
have to change and has sufficient space to accommodate any future
growth?
I have no issues with planning for success, but one of the key issues
with allocating addresses is justifying the request. Typical allocation
policies, at least from the RIR perspective, take total number of
networks/devices into account when responding to an address block request.
In addition, I know that all LISP work is marked as "experimental"
but let's also keep in mind that there are companies out there that
start making business out of LISP.
That is their choice.
Should there be a termination date for this allocation?
I do not see IPv6 addressing space as a scarce resource, and for the
same reasons I cited above I wouldn't put a termination date.
Obviously, IANA may decide to allocate the prefix only for a limited
amount of time and decide in few years whether or not to make it a
definitive allocation.
That is definitely one possibility.
Regards,
Brian
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
