On 4 Dec. 2013, at 16:26 , Ronald Bonica <[email protected]> wrote:
>>
>> PITR should announce the largest aggregate possible, ideally the /32.
Hi Ron,
note as well that I used the word “ideally”… because IMHO it will not happen in
reality ;-)
The sentence came along with the idea to avoid deploy personal PITRs.
If every LISP site gets an EID prefix and announces it in BGP by himself we
would end up polluting the BGP table with EID prefixes.
This is something we absolutely do not want.
To avoid misinterpretation I would change the following sentence currently in
the document (section 4)
To guarantee reachability from the Legacy Internet the prefix may be
announced in the BGP routing infrastructure by one or more PITR(s) as
part of larger aggregates (ideally just the entire LISP EID block).
in just
To guarantee reachability from the Legacy Internet EID prefixes may be
announced in the BGP routing infrastructure by one or more PITR(s) as
part of larger aggregates.
and conclude the section with the paragraph (proposed in previous discussion
with Geoff):
The EID block must be used for LISP experimentation and must not be
used as normal prefix. Interworking between the EID block sub-prefixes
and the non-LISP Internet is done according to [RFC6832]
and [I-D.ietf-lisp-deployment].
Do you folks think this is OK?
Luigi
>>
>
> Luigi,
>
> Is this really what is going to happen?
>
> If a PITR announces the entire /32 into the global Internet, it puts itself
> on the forwarding path for the entire /32, and incurs the cost associated
> with transporting traffic towards every site in that /32. This is supportable
> only if the PITR operator is somehow compensated for carrying all of that
> traffic.
>
> Isn't it more likely that the PITR operator will advertise only slices of the
> /32, with each of those slices being assigned to either its customers (from
> whom it collects revenue) or the customers of other operators with whom it
> has made financial arrangements?
>
> Ron
>
>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
