> From: John Curran <[email protected]>

    > If the EID assignments have potential to impact the ISPs currently
    > using IPv6 (e.g. if such assignments might also end up being used as
    > provider-independent IPv6 blocks by their recipients and show up in the
    > IPv6 routing table)

Assignments from the 'EID only' block (terminology gets a bit confusing,
_any_ allocated IPv6 address _can_ be used as an EID, I'm speaking of the
proposed 'EID only' block - although that block would almost certainly _also_
wind up being advertised in the DFZ, for purposes of communication with
'legacy' [i.e. non-LISP] sites) would, if they are advertised, probably wind
up being routed rather idiosyncratically - e.g. in an 'anycast' type way,
where packets to a destination in the 'EID only' block are routed to the
nearest PITR.

So anyone hoping to get a block of them, and use them as 'vanilla' PI space,
would probably wind up Losing Big; their attempt to route the traffic to
themselves might not work (depending on if people filter out more-specifics
for that block, etc, etc).

    > One tiny example: to minimize long-term growth in IPv6 routing table
    > size, issuance via "sparse-mode" has been done in most cases, whereby
    > space is reserved for future adjacent growth. Lots of discussion took
    > place about this, and it is now a fairly common practice.

This would not (and should not, for optimal use of the address space) be true
for EIDs. Having one's EIDs in one block, or two, should have no effect on the
DFZ routing. (It might have effects on the amount on config required on,
say, firewalls, but that's different.)


    > From: David Conrad <[email protected]>

    > My impression (others will correct me if I'm mistaken) is that as part
    > of a transition phase, it would be helpful (required?) if EIDs were
    > routed to enable end sites which have not yet deployed LISP to be able
    > to communicate with sites that have deployed LISP.

This is exactly my impression too, and for that very reason.

Perhaps I'm confused, but it seems to me that pretty much the only thing this
block buys someone is that one can tell, simply by looking at such IPv6
addresses, that they are EIDs - one don't need to do a mapping lookup cycle
to see if a mapping exists. And maybe there are some other things too (e.g.
the whole block can be anycast routed to the nearest PITR).


    > From: John Curran <[email protected]>

    > our indirect approach of relying primarily on provider-based
    > hierarchical address assignments as a control knob on routing table
    > size has performed adequately in the past, but we have no assurance
    > that it is up to the job going forward.

Especially as people can get PI to avoid provider lockin, are multi-homed (or
say they plan to be, so they can get a PI), etc, etc...

    > suddenly having them universally available in traditional IPv6 routing
    > without some other feedback system on routing table growth is not
    > without risks.
    > ...
    > we also have to make sure that the deployment of EID prefixes does not
    > cause problems for the existing operators, many of who have worked
    > diligently through the RIRs to adopt specific policies for how IPv6
    > prefixes are issued.

Again, I would _hope_ that if 'EID-only' addresses are DFZ-routed, they will
be so in a very restricted way (e.g. all ISP's filter out 'more specifics' in
this block, and the whole block anycast-routed to the nearest PITR) which
makes the unsuitble for 'backdoor PI space'.

And maybe we should say that, in big letters, so people don't even _think_
they can get 'backdoor PI space' that way.

        Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to