PPVPN @ 57 th IETF meeting

1. IS-IS as the PE/CE Protocol in BGP/MPLS VPN draft-sheng-ppvpn-isis-bgp-mpls-00.txt PPVPN @ 57th IETF meeting shengc@huawei.com liu_yu@huawei.com lidefeng@huawei.com chenyunqing@vip.sina.com Slide 1

2. Motivation • In 2547 VPN, PE-CE routing protocol can be EBGP,OSPF,RIP,Static routing etc,IS-IS can also assume this function. • In OSPF case ,there are draft-rosen and draft-ishiguro addressing the problem. • In IS-IS case,no such draft,this draft will fill the vacancy. Slide 2

3. Benefits • When IS-IS is already used in customer network. • CEs need only run one routing protocol. • Little impact on transition from legacy customer network. • A new choice for CE-PE routing protocol. Slide 3

4. Contents(1/5) • Fundamental Model • Assumptions No back door IS-IS link between CEs in the same VPN. • Multiple IS-IS instances(Applicable to Extended Model) • Support Multiple IS-IS instances in one PE • Each instance bound to one specific VRF. • IS-IS interaction with BGP on PE PEs have the capability to import IS-IS and BGP routes to/from each other in particular VRFs. • Import BGP routes to IS-IS as external routes,TLV 130. • Narrow IS-IS metric style:0-1023, • Wide IS-IS metric style:0-4261412864(2^32-2^25),TLV 135 Slide 4

5. Contents(2/5) • Extended Model • Support back door IS-IS link between CEs of the same VPN. Slide 5

6. Contents(3/5) • Extended Model • Carry IS-IS information with BGP Extended communities (first two bytes) • IS-IS Route Type Extended Communites Attribute. • Level type (bit 1/byte 3rd,0/1:level 1/2) • Metric style type (bit 2/byte 3rd,0/1:narrow/wide) • TLV Reachability type (0/1:internal/external) • Metric type (0/1: internal metric/external metric) • Sham-link endpoint address (1:sham link end) • IS-IS System ID Extended Communites Attribute • MED. The value of the IS-IS distance associated with the route, plus 1. Slide 6

7. Contents(4/5) • Extended Model • Route loop prevention on PEs • PE1 and PE2 both import BGP routes into their attached CE sites, the route loop maybe happen. • To avoid the route loop, it is assumed here that both PE1 and PE2 act as L1/2 router and there exists level-1 adjacency between each PE-CE link. • Refer to RFC 2966 to avoid route loop (use up/down bit). • IS-IS interaction with BGP on PE • When Egress PE receives a VPN-IP routes, converts them back to IS-IS. • The creation of IS-IS LSP bases on IS-IS route original information carried by BGP extended communities Slide 7

8. Contents(5/5) • Extended Model • Sham-link Creation • Each end PE assigns an shamlink endpoint address. • BGP imports direct route designated as source shamlink endpoint address on PE2. • Converted BGP route carries BGP extended communities (sham-link endpoint address bit set,IS-IS System ID Extended Communites Attribute equal to the System ID of the IS-IS instance on the PE2. • PE1 receives the route, gets the IS-IS System ID in BGP route, checks the sham-link endpoint address bit, create shamlink or not. • PE1 adds Neighbor reachability TLV in its self-originated LSP and floods it to CE1. • Similar process will happen on PE2. • When PE finds that the system ID of the other end of the sham-link is changed, flushes the old LSP and generates new LSP according to the new system ID got from BGP route. Slide 8

9. Next Step • Please review the draft • Comments are welcome • Discussion and revision • Can it progress to WG draft? Slide 9