RE: Advancing the Protocol and Morin Drafts

["Ross Callon" <[e-mail]>]

> As for one protocol vs. two, one of the key points is timing.
> CR-LDP could be killed 8 years ago in the debate against 
> RSVP-TE, because there was no deployment. Cannot do that when
> there are large production networks out there. 
>
> Thanks,
> Luyuan

Speaking as the AD overseeing this working group (but understanding that
there are limits to what an AD can or should do), I think that it might
be useful to think about the context of where L3VPN and our current
range of options came from.

L3VPN of course was created when PPVPN working group was split into two
(the layer 2 part, and the layer 3 part). PPVPN was itself started quite
a few years ago. At the time there was considerable friction between the
people who wanted CE-based VPNs (using IPsec), people who wanted virtual
router based solutions (and there were at least two and possibly more
quite different virtual router based proposals), and people who wanted
BGP/MPLS based solutions. After a fair amount of argument, much of which
preceded the chartering of the PPVPN working group, it was agreed to
work on all three approaches. 

As such there have always been multiple layer 3 approaches that could be
used to support virtual private networks (not even mentioning the layer
2 approaches). To me it looks as if we are well past the point where we
expect that we will end up with only one single solution. 

On the other hand, we are working on standards for a reason: There is a
huge advantage to the industry as a whole, and to any users of
networking technology, if it is possible to build networks out of
equipment from many different manufacturers. Also, the technology used
is likely to be significantly better or at least more broadly applicable
if it has been reviewed by many people from multiple different
backgrounds and multiple different points of view. 

Thus, if we end up with 20 different solutions, or five solutions each
of which has four or five fundamentally different major subsets, and if
no two vendors implement overlapping subsets of these 20 different
solutions, then we have failed as a standards setting organization. 

If we end up with two or three options, and if each of the two or three
options has a single subset which is clearly defined and is implemented
by a wide range of vendors, then we have been relatively successful (and
probably as successful as we can hope to be in this particular space). 

Thus, the question of whether to accept as a working group document a
document that will define one proposed profile (or a small number of
profiles) for a hopefully interoperable solution, seems to me to be
orthogonal to the question of whether to accept a new set of
requirements which are likely to lead to a different solution (which
might in the future lead to an additional profile). 

Ross