IETF 68, Prague 2007 Update on “BGP-based Auto- Discovery for L1VPNs” draft-ietf-l1vpn-bgp-auto-discovery-01.txt Don Fedyk Hamid Ould-Brahim Yakov Rekhter

IETF 68, Prague 2007 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 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 Current NLRI CEPE Customer Realm VPN-PPI PPI | Length (1 octet) | | PPI Length (1 octet) | | PPI (variable) | | CPI AFI (2 octets) | | CPI (length) | | CPI (variable) | CPI Provider Realm

IETF 68, Prague 2007 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 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 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 Next? Solicit WG feedback on the new NLRI proposal.