1 / 7

BGP-based Auto-Discovery for L1VPNs

An update on the draft-ietf-l1vpn-bgp-auto-discovery-01.txt discussing changes made in the 00 version and proposing new NLRI for L1VPNs.

hurtd
Download Presentation

BGP-based Auto-Discovery for L1VPNs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related