[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GROW] LISP at GROW
> -----Original Message-----
> From: Dino Farinacci [mailto:dino at cisco.com]
> Sent: Tuesday, August 05, 2008 1:27 AM
> To: PAPADIMITRIOU Dimitri
> Cc: grow at ietf.org
> Subject: Re: [GROW] LISP at GROW
>
> > i) EID value space variation can result in triggered updates (e.g.
> > permanently remove a contiguous set [j,..,m] of intermediate EID
> > from an
> > aggregate [a,..,z] results into two aggregates [a,..,i] and
> [n,..,z])
>
> Well EID-prefix assignments will be relatively static. So I don't
> think we'll nearly have the flapping as the underlying
> network. And it
> seems the underlying network holds together fairly well with
> the issue you state above.
"relatively static" is certainly dependent on needs/usage and which
entity will manage the EID space and its associated policy. also, it
suffices that an application requires permanence of the EID across a
sequence of RLOCs to invalidate this assumption.
> > ii) with an overlay + out-of-band EID-to-RLOC resolution:
> the ETR once
> > receiving a MAP Request does not check forwarding towards
> the RLOC it
> > sends back to the ITR. the ITR once receiving a MAP Reply
> can not rely
>
> Right, it doesn't because it is really hard to do that without
> building a complex system.
>
> > on egress RLOC as distributed by BGP to check its actual
> reachability.
> > thus, resulting in false positive and the system will
> stabilize once
> > the
> > BGP RLOC will stabilize. As a consequence there is no
> improvement of
> > the
> > BGP local stability (assuming RLOC are completely
> aggregatable) or BGP
> > global stability (otherwise).
>
> This is no different than we have today. Are you saying what we have
> today is not sufficient?
I just point that no improvement is achieved in contrast to what has
been previously stated (and this because the bottomline is the same.) on
this specific goal.
> > iii) otoh you have the reverse issue, true negative. the BGP ALT is
> > flapping preventing EID reachability while the RLOC are actually
> > reachable via the BGP. to solve this BGP ALT must be at least as
> > stable as the underlying BGP.
>
> The ALT will not flap, I don't know why you think that. We have
> logical tunnels between eBGP peers that are very resilient
> since there is a robust network underneath it.
Even if (logical) links are failure-safe (at least at the extend they
can be recovered within a timeframe that does not impose any
notification/update or their recovery does not impose a topological
change) just think about failures of the leafs of the BGP-based ALT
distribution tree i.e. TR like indicated in response to Dave or root
failure since the ALT topology structure is a tree.
> And since the EID-prefixes are added and deleted based on
> subscription
> based contracts, the flap rate is more like months and years, then
> what you are thinking.
See above.
Thanks,
-d.
> > Hope this clarifies that issue,
> > -dimitri.
>
> Well, not really.
>
> Dino
>
>
_______________________________________________
GROW mailing list
GROW at ietf.org
https://www.ietf.org/mailman/listinfo/grow