[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-morin-l3vpn-mvpn-considerations-01.txt
Tom,
I think that splitting the current solutions document into two is a
great idea. The current solutions document is pretty much unreadable.
Presumably, the one solutions document would consist of the mandatory
elements defined in draft morin?
Thanks,
John
>-----Original Message-----
>From: Nadeau Thomas [mailto:tnadeau at lucidvision.com]
>Sent: Monday, March 10, 2008 3:55 PM
>To: Rosen Eric; Yakov Rekhter; l3vpn at ietf.org
>Subject: Re: Comments on draft-morin-l3vpn-mvpn-considerations-01.txt
>
>
> Guys,
>
> As entertaining as this sparring is, it is not brining
>us any closer to resolution. Can't we all just get along? *)
>
> What we (at BT) want from this document is pretty
>simple and is achievable within the confines of a WG document:
>one set of mandatory operations/constructs with the rest set
>to optional. It seems the only way to achieve this is to write
>two WG solutions documents and let the market decide.
>
> --Tom
>
>
>> 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.
>>
>>
>>
>>
>>
>>
>
>