1. Reconciling the L3VPN Authentication Drafts (Singing “Kumbaya”) M Behringer R Bonica

2. The Drafts Draft-ietf-l3vpn-l3vpn-auth –Provides a method through which customers can detect SP misconfiguration –Does nothing to prevent misconfiguration –Delegates authentication task to the CE Draft-behringer-mpls-vpn-auth –Reduces the probability of SP misconfiguration –Customer does not detect misconfiguration if it does occur –Delegates authentication task to the PE

3. The Dilemma The two drafts are similar, but not identical Options –Merge –Let them both live –Kill one, progress the other

4. The Opportunity Both drafts bring something unique to the table Killing either would take something away from the user community

5. Lots of Pro’s And Cons Fuel for a good religious war Religious wars don’t bring us to convergence But they are fun –Join us in the bar tonight for a continuation of the religious war

6. Comparative Anatomy PE obtains token from CE –BGP extended community from received from CE –New protocol with CE –Hashed authentication key from CE-PE routing protocol PE distributes token throughout SP network –BGP extended community –New BGP attribute

7. Comparative Anatomy (Continued) PE uses token –Distribute to CE using BGP community or new protocol –Use to decide whether or not route will be installed based upon local MD5 authentication key used in PE-CE interface routing protocol

8. How Do we Converge Converge on a common mechanism for distribution of the token within the SP network Add a third mechanism for obtaining token to draft-ietf-l3vpn-l3vpn-auth –Derive the token from the PE-CE MD5 key Add a third application for the key at the egress PE –Use it to decide whether to install the route

9. Kumbaya