isoftwire-8----Page:54
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
|
Notes (4) What about the Extended Communities approach? idea is to advertise AF NLRI reachability along with a new Extended Community that carries IP tunnel capabilities therefore each egress AFBR must advertise the same tunnel information O(# of AF updates) times. Example: if AFBR advertises 1000 BGP updates for prefixes in that AF, then same IP tunnel information is advertised 1000 times. This is 999 more times than is necessary. Extended community only defines a bit-mask indicating the type of tunnel supported. No means exists to define a set of tunnels, the encapsulation parameters of the tunnels in the set or, the order of preference of tunnels in the set. also assumes that IP tunnel end-point is the same as the BGP next_hop. True when using MPLS LSP but perhaps not true when using IP tunnels. In fact IPsec will likely use an IP address that is completely different from BGP next_hop. Therefore IPSec protection will clearly require special tunnel capability advertisements that identify the IPSec tunnel end-points which Extended Communities does not support References: draft-raggarwa-l3vpn-tunnel-attribute-00.txt |