I think Yakov's reply makes it pretty clear that adoption of this
document
as a WG document at the current time is premature.
I was prepared for someone to say that the issues I raised can
be worked
after the document is accepted. However, we see from Yakov's
answer that
he, at least, wants to suppress discussion of all the
remaining issues
(after all, they're all FUD ;-)). I didn't think my reputation in
this WG
was that of a FUD-provider, but YMMV ;-)
For the kind of document that draft-morin seems to be, I think it is
the job
of the authors to investigate all the issues, not to say "we won't
consider
any issue until some else proves beyond a shadow of a doubt that
there's a
real problem". Of course, I'll be happy to work with the authors
to flesh
out all the arguments pro and con. I'm not trying to prove
that the
BGP-based scheme won't work, but I'd have thought that everyone
knows that
all proposals have pros and cons; a "considerations" document
should bring
out all the issues.
In fairness, Yakov isn't one of the authors of the document, so it
would be
interesting to know whether the authors of the document agree that
there is
no need to discuss any of the issues I've raised.
A few of the more outrageous comments do require some reply:
why should the draft talk about this [variety of factors for which
we lack
hard data] since facts are scarce ?
Any choice which is based on opinion rather than facts is a
risk, and a
"considerations" document should certainly make it clear when
such risks
exist.
Moreover since PIM is based on unreliable message exchange, "join
latency"
with PIM could be in 10s of seconds.
The worst case join latency in either case could be arbitrarily
long, but
I'm sure everyone knows ((well, almost everyone ;-)) that's it's the
average
join latency that is important. Since packets don't usually get
lost in the
backbone, that's not much of an issue. I don't think it takes
a lot of
fancy analysis to determine that it's faster to send a data
packet from
point A to point B then to send it from point A to an
intermediate point
where it is processed and then afterwards sent along to point C.
One can
argue that the latency increase isn't significant, or that
it's a good
tradeoff against something else, but it's just silly to deny
that the
latency increase exists!
could please quantify "significantly" as you assert that
"BGP will
significantly increase the latency".
I did not state that BGP will significantly increase the
latency, I said
that we do not have the data to determine whether BGP will
significantly
increase the latency.
A "significant increase" would be one that causes a visible
effect to the
users of a multicast-based application.
"Dampening of withdrawals [as opposed to updates] of C-multicast
routes
does not impede the multicast join latency observed by MVPN
customers,"
Sure, but it doesn't have the same effect on churn reduction as
does join
dampening, and it has other side-effects as well. This is certainly
an area
that would benefit from more analysis in any "considerations"
document.
Since you are a co-author on that draft, you should be aware of this.
I'm glad you remembered that I'm a co-conspirator (err, co-
author) of the
BGP-based multicast control plane. As a co-author, I am familiar
with lots
of issues that might not necessarily be obvious to the
authors of
draft-morin. Further, I appear to be the only co-author who
thinks that
both BGP and PIM have merits, and that it is important to do
a pretty
thorough and unbiased comparison.
As for the last "effect on existing L3VPN route reflector systems",
please note the the following text in Section 15 of
draft-ietf-l3vpn-2547bis-mcast-bgp:
Moreover, Route Reflectors used for MVPN do not have to be
used for VPN-IP routes
And as a reminder, you are a co-author on that draft !
Yes, I am well aware that you can add new RRs expressly to handle
multicast
routes. In a "considerations" document, the need (or lack of
need) to do
this is one of the considerations that should be discussed. Unless
the SPs
are willing to say up front "not to worry, we don't care how many
additional
RRs we need, they come for free and do not increase our operational
burden".
As you know, I am a big fan of the 2547 technology :-), but the
issue of how
the VPN-IP routes affect BGP generally (and how much "BGP churn"
they cause)
has always been with us. At least VPN-IP routes do not
behave much
differently than IP routes, since updates are still triggered by
topology
changes and not by enduser activity. MVPN introduces a
different set of
dynamics to BGP and the impact on the rest of the BGP system is
certainly a
consideration that needs to be better understood.
It is fair to point out that additional BGP activity is at least
partially
compensated for by reduced PIM activity. On the other hand, PIM
activity
doesn't impact the BGP system, so this comparison is not
straightforward.
In fact, can you explain why having one architecture for unicast
VPN (aggregated routing) and another architecture for multicast VPN
(virtual routers) is any better than having the same architecture
for both unicast and multicast VPN ?
I think the choice between the two schemes should be based
not on the
elegance of the architecture but on the multitude of facts that
determine
(a) how well the multicast applications in the enterprise will be
supported,
and (b) how much operational impact they have on the SP.
Further, multicast routing is really a very different thing than
unicast
routing, and there is no history of success in combining the
two into a
single architecture (e.g., MOSPF).
This is not to say that BGP is a poor choice, but just to
explain why I
don't think that the uniformity of the architecture is the
overriding
considerations.
First of all, autoRP is a cisco proprietary technology. Asking
standards to support cisco proprietary technology is inappropriate.
If an enterprise is using proprietary technology, and if a SP
wants to
provide MVPN service to that enterprise, then I think the SP will
certainly
want to know whether he has to tell the enterprise "no MVPN service
for you
until you change your deployed technologies" ;-)
A large number of enterprises use Cisco technology, and I imagine
that other
vendors would like to be able to provide PEs that support those
enterprises.
supporting BSR without MI-PMSI has been explained in the
presentation at
the L3VPN WG meeting (with you as one of the co-authors
on that
presentation).
Many of the presentations we've given over the years presented
solutions
which turned out to be unsatisfactory. Certainly the support
or lack
thereof for BSR is something that a "considerations"
document should
examine.
realistically, for the foreseeable future, the use of an MI-PMSI
is
going to remain the only method of aggregation.
Do you speak just for cisco, or for all other vendors as well ?
I would highly recommend that before eliminating the MI-PMSI, the
SPs should
get solid delivery dates from their vendors for upstream-assigned
labels!
;-)
it is not clear that segmented inter-AS S-PMSIs are scalable at
all.
Are they less scalable than non-segmented inter-AS S-PMSIs ?
In my mind, the issue is whether there's a real good inter-provider
solution
at all.
If less work for the PEs is the goal, then one should not run 2547
VPNs,
Well, I'd like to hear the SPs say that they don't care how much
additional
work the PEs have to do! Or that they don't care how much
additional
coordination they have to do with their customers, or that they
don't care
how many changes the customers have to make before they can buy
the SPs'
service.
the recommendations should reflect position of SPs, not vendors
(and you
are part of the latter, not the former).
I've yet to hear any SP say that they don't want my input because I
work for
a vendor. If any do feel that way, I'm sure they can speak
up for
themselves.