Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt

From: [email-masked] (Noel Chiappa)
Date: Wed, 13 Mar 2013 10:21:59 -0400 (EDT)

> From: John Curran <[email-masked]>

    > 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-masked]>

    > 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-masked]>

    > 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

---

From: John Curran <[email-masked]>
Date: Wed, 13 Mar 2013 10:39:22 -0400

> they can get 'backdoor PI space' that way.

If it is documented that 'EID-only' addresses are not intended to 
be traditionally routed, that might help significantly in limiting
concerns about potential impact to existing operations (aka "policy
issues") that might otherwise be posed by its issuance.

FYI,
/John

Disclaimers:  My views alone. Small topics herein; mental choking hazard.

---

From: Darrel Lewis <[email-masked]>
Date: Wed, 13 Mar 2013 10:37:41 -0700

> the whole block can be anycast routed to the nearest PITR).

I don't think you are confused.

I think, as long as we support the 'conversion' of existing prefixes to EID prefixes*, then the complexity in the implementation to support this behavior must exist, and the corresponding value of having some destinations you don't have to ask the mapping system about is reduced.

-Darrel 

* and I think supporting this is a MUST

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Mar 2013 11:10:05 -0700

>> addresses, that they are EIDs - one don't need to do a mapping lookup cycle

Well you do if you need to populate your map-cache with RLOCs. 

As I said, the reason for the /12 is to know who aren't EIDs (with a supported configuration knob) so legacy forwarding in an ITR or PITR does not drop packets while doing a non-fruitful lookup. 

>> the whole block can be anycast routed to the nearest PITR).

This is an added benefit yes. 

> I don't think you are confused.

Noel is definitely not confused. 

> I think, as long as we support the 'conversion' of existing prefixes to EID prefixes*, then the complexity in the implementation to support this behavior must exist, and the corresponding value of…

Right - the knob allows you to wholesale know if the lookup will provide RLOCs. 

Dino

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sander Steffann <[email-masked]>
Date: Wed, 13 Mar 2013 21:18:09 +0100

Hi Noel,

> the whole block can be anycast routed to the nearest PITR).

I think you are right.

My primary concern is about the reliability of those PITRs. I am sure that for the experimental phase a few organisations will provide PITRs. I am afraid that when the experiment is successful the traffic on those PITRs will become too much to be able to offer it for free. And if just one of the PITRs is unreliable (old software, not enough bandwidth, upstream problems, etc) then all traffic it attracts will become unreliable. For experimenting that will just be annoying, but for people looking at more serious use that will be a show-stopper. As I am already running a production LISP setup this alone would make the EID-only block unusable for me/my customers.

And, as I am running my current LISP production stuff using a prefix I got from my RIR, having other organisations using the only-do-lookups-for-the-special-EID-block would cause less optimal routing to my sites: it could have used LISP, but because the lookup is never done that traffic will go to my own PITRs.

So, if these are the only things that this block buys us then I think we should just abandon the idea...

Cheers,
Sander