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

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

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

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

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

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

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

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

Kumbaya