Download
update on bgp based auto discovery for l1vpns n.
Skip this Video
Loading SlideShow in 5 Seconds..
Changes from 00 Version PowerPoint Presentation
Download Presentation
Changes from 00 Version

Changes from 00 Version

0 Views Download Presentation
Download Presentation

Changes from 00 Version

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Update on “BGP-based Auto-Discovery for L1VPNs”draft-ietf-l1vpn-bgp-auto-discovery-01.txtDon Fedyk dwfedyk@nortel.comHamid Ould-Brahim hbrahim@nortel.comYakov Rekhter yakov@juniper.net IETF 68, Prague 2007

  2. Changes from 00 Version • Added section 4 referring to BGP TE-Attribute. • For example a PE may learn from the remote PEs, the switching capability, the maximum LSP bandwidth of the remote l1vpn interfaces. • The auto-discovery role is just to distribute that information. It is up to the signaling (on CE and/or PE) to use or not the TE information related to the CE-PE links. • Added section 5 on scalability • Mostly focusing on BGP as an auto-discovery mechanism for VPNs. • Completed section 6 on Security Considerations • Very preliminary. • Need more input. • Added section 7 on IANA considerations. IETF 68, Prague 2007

  3. Proposal on the NLRI • Today PPI is carried within the NLRI. • Proposal: Remove distributing PPI information in the discovery process. • Why? • Because BGP next hop is already carrying information about reaching remote PEs. • This information is useful only when resolving the egress CE-PE link  useful only when signaling reaches the remote PE. • Advantages? • PPI becomes local to the PE (A PE needs only to advertise its address not the set of ports attached to L1VPNs). • In the case of inter-provider (domain) scenarios, one provider will not need export its internal Provider port information. IETF 68, Prague 2007

  4. Current NLRI CE VPN-PPI PE CPI PPI Customer Realm Provider Realm +---------------------------------------+ | Length (1 octet) | +---------------------------------------+ | PPI Length (1 octet) | +---------------------------------------+ | PPI (variable) | +---------------------------------------+ | CPI AFI (2 octets) | +---------------------------------------+ | CPI (length) | +---------------------------------------+ | CPI (variable) | +---------------------------------------+ IETF 68, Prague 2007

  5. Implications • Need to uniquely identify CPI in the auto-discovery and signaling mechanisms. • A proposal is to use a Route Distinguisher and build VPN-IPv4 and VPN-IPv6 CPIs. • The tuple <RD, VPN-IPv4/6> need to be carried as well in signaling. • On the NLRI: • Remove the CPI Length and the CPI AFI fields. • Replace PPI field with RD field. • On the BGP MP-attribute • No need for new SAFI for l1vpns, just reuse existing layer-3 VPN SAFI information (VPN-IPv4/VPN-IPv6). IETF 68, Prague 2007

  6. New NLRI Proposal +---------------------------------------+ | Length (2 octets) | +---------------------------------------+ | RD (8 octets) | ~ ~ +---------------------------------------+ | CPI1 (length 1 octet) | +---------------------------------------+ | CPI1 (variable) | +---------------------------------------+ | CPI2 (length 1 octet) | +---------------------------------------+ | CPI2 (variable) | +---------------------------------------+ The RD assures uniqueness of the NLRI  Need to be carried within the signaling as part of VPN-IPv4/VPN-IPv6 address as well. IETF 68, Prague 2007

  7. Next? • Solicit WG feedback on the new NLRI proposal. IETF 68, Prague 2007