Hello Albert,
> What about this:
>
> Additionally, LISP’s approach to solve the routing scalability problem
> [RFC4984] is that with LISP the Internet core is
> populated with RLOCs whileTraffic Engineering mechanisms are pushed to
> the Mapping System [Quoitin]. With this RLOCs are quasi-static and
> hence, the routing system scalable [Quoitin].
I very much like the first sentence. My concern was more the "quasi-static
and highly aggregatable". I'm actually nor sure what "quasi-static" means for
you. But from your reference to [Quoitin] I assume you mean the RLOC
assignment discussion in the section "Shrinking The FIB" (?)
While it is an interesting read there is a "flaw", mainly the fact that you
will have difficulties to establish hierarchies at a larger scale in the real
Internet. The picture you see from BGP table snapshots are misleading, they
do not show the private peerings, which by far outnumber the uplink/downlink
relationship. As a result you see a lot of stubs that aren't.
Not to mention the Internet is allergic against hierarchies ;-) (maybe more
for business reasons these days).
The good thing: you don't have to stress this point. If every AS announces
one/few networks in BGP that cover RLOCs then my wild guess is we talk about
50k prefixes, which is a 90% reduction and still a fantastic story.
But maybe my last point is something you see covered by your new wording -
these RLOC networks are indeed static.
> The goal of the draft is to make easier to read the LISP specs, this
> requires explaining the big picture and, in some cases, simplifying.
> PIs are a great analogy to EIDs, what about this:
>
> EIDs do not contain inter-domain topological information and can be
> thought as Provider Independent (PI [RFC4116]) addresses.
Ah this is nice. Maybe "[...] and can be thought as an analogy to Provider
Independent ..." ? Anyway, got your point now.
> What I am trying to say is that in most cases LISP only requires a
> software upgrade, again I am trying to explain the big picture with as
> few details as possible. What about this:
If introducing LISP capability is a software upgrade or a hardware
replacement is heavily depending on the kind of hardware. I liked your
original first sentence very much
the only
required changes to the existing infrastructure are to routers
connecting the EID with the RLOC space.
That is the key: the core - in the sense of routers between xTRs - remains
untouched, even edge/access routers that are not dealing with LISP remain
untouched. It's only the xTRs and PxTRs that require some work. Saves effort
and money - and I agree this is a bigger picture.
> Such LISP capable routers, in most cases, only require a software upgrade.
This was the sentence I stumbled over. Now ... maybe you read it different
than me:
(a) the router is already LISP capable. Then at most it's a software upgrade
to get the full functionality. Okay, agree.
(b) You want to make the router LISP capable. In this case a software upgrade
works only for software based routers, may work for fully programmable NP,
may work for FPGA-based systems and will fail for ASICs that don't do LISP by
design. I would not make any statement here :-)
>> The "publicly accessible" shows up multiple times (yes, consistent :-) .
>> [...]
>
> Agreed, I´ll change this on the upcoming draft.
Thanks!
Regards, Marc
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
