Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Robert Raszuk <raszuk@juniper.net>]

Hi Dino,

One question ...

> Well if a path changes in the core to reach a specific ETR address, you 
> want change quickly. And that will use BGP like it does today.

Correct.

> LISP is not replacing BGP. LISP is conveying 1) the ETR is up, 2) the 
> ETR's CE-PE link is up and 3) the ETR thinks the PE is up. BGP still 
> controls the policy and reachability of the locator addresses (the 
> addresses of the ETRs).

If we assume that ETR addresses (unicast or anycast) are in the BGP as 
today, and agreed that there would be much less of them then EIDs why 
LISP (presumably you are referring to the data plane idea) has to convey 
if ETR is up ?

Am I right that the assumption is that the major reason for this is that 
you do not want to run BGP on ETRs ? You would not need to ... You could 
 even run BFD between PE-CE/ETR to indicate to PE that CE/ETR is down. 
 PE would then re propagate this fast in BGP.

I am just trying to see a consistency in reachability propagation end to 
end. BGP may say ETR is up while LISP data plane idea that is went down. 
Actually for unicast this may work well but for anycast ETR address I am 
not that sure during the failure of one ETR from given anycast group.

Cheers,
R.


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg