Subject: RE: [pim] Fwd: Multicast in MPLS/BGP IP VPNs

From: Nidhi Bhaskar <[email-masked]>
Date: Thu, 13 Oct 2005 15:58:56 -0700 (PDT)

Hi, Marshall,

Thanks for bringing this thread to the PIM WG's attention.

Didn't think anyone would seriously consider booting out a deployed
protocol, in favor of something that is not defined or well
understood. The lack of volume on the (l3vpn) thread seemed to
indicate the idea wasn't gaining any particular traction. But I could
be wrong.

But in general, I think the PIM WG & various other multicast folks on
this alias need to pay attention to this discussion. From my point of
view the right process for eliminating one of the two options would be
to:

o Agree on requirements for multicast routing protocol in
   VPN space. [Maybe good for mboned to provide input on the
   requirements currently defined.]
o Describe how BGP "extensions" could meet these requirements.
o Describe how PIM "extensions" could meet these requirements.

Then we have enough information to pick our poison ;). So, please do
raise your concerns.

Nidhi.

PS: I've heard rumors that on the L3VPN planet, BGP is extended
to carry everything, including Shakespeare ;). So extending it for
multicast is inline with the "laws of nature" there.

------ Forwarded Message
From: Marshall Eubanks <[email-masked]>
Reply-To: Marshall Eubanks <[email-masked]>
Date: Fri, 7 Oct 2005 22:14:37 -0400
To: <[email-masked]>, <[email-masked]>
Subject: [pim] Fwd: Multicast in MPLS/BGP IP VPNs

Hello PIM-WG;

I am forwarding this (fairly long) mail thread from the I3VPN list as
I think it is relevant to PIM. Here are the issues as I understand
them :

- Bisdikian et al. want to deny the use of PIM in multicast VPN's,
even though there are
deployed solutions with this technology

Specifically, the proposal is to remove PIM as an option in Section 5 of

draft-ietf-l3vpn-2547bis-mcast-00.txt .

- The mandated solution will be to use BGP as the multicast routing
protocol  even though (AFAIK) there are not any any multicast BGP VPN
implementations as yet.

- One worry is the requirement of propagating soft state keep-alive
packets. I know that there are people working on fixing this in a VPN
context,
but I don't know what the status of these implementations are.

This seems very ill-advised to me, but I would appreciate some other
viewpoints before I start making a fuss  in L3VPN WG. I worry about
bifurcating the multicast world, about L3VPN reinventing the multicast
wheel (possibly re-making a bunch of mistakes), and also about how
multicast routing information will get propagated from PIM domains to
and from BGP L3VPN's. I don't want L3VPN to create something that can
only be used for walled gardens. (I may be wrong about this, but I
have seen nothing on how to do this.)

Regards
Marshall Eubanks

---------- Forwarded message ----------
From: Chatschik Bisdikian <[email-masked]>
Date: Oct 7, 2005 11:46 AM
Subject: RE: Multicast in MPLS/BGP IP VPNs
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
[email-masked]

Dear Richard,

I appreciate your comments and support. It was my understanding all
along that your initial note was about fact finding rather than
arguing against one solution or another. So my response tried to give
a more complete reasoning behind our proposal.

We're acknowledging the maturity level of the PIM protocol
implementations but at the same time we recognize that the scalability
issues of PIM is inherent to the protocol itself: The presence of soft
state results in the regular/persistent transmission of control
(refresh) messages of various sorts. This is a point of consideration
for the PIM-SM family of protocols independently of whether PIM is
used within multicast VPNs or not.

On the other hand BGP is a "solid state" (!!!) protocol and, as such,
has its own issues of concern (say, resources have to be reserved and
set-aside to maintain the various BGP communications channels between
the PE-routers, or the PE-routers and the BGP route-reflector).
However, BGP is an integral part of the "2547bis-mcast" framework for
VPNs no matter whether BGP is to be used to transfer PE-PE multicast
routing information or not -- and I have yet to hear arguments against
removing BGP altogether from 2547bis-mcast VPNs. Therefore, why not
focus our efforts in building the baseline instance of multicast VPN
based on the "2547bis-mcast" framework around BGP.

I understand that adoption of our proposal does not necessarily mean
that within a day or two we will have a fully operational
"2547bis-mcast" VPN. It will, nevertheless, reduce considerably the
number of parameters and operations that we have to tackle and this
will hasten the time it will take to develop an operational,
standardized instance of a multicast-supporting VPN.

  Dr. Chatschik Bisdikian
  IBM T. J. Watson Research Center
  19 Skyline Drive, M/S 3S-B34
  Hawthorne, NY 10532, USA
  tel#: +1 914 784 7439
  fax#: +1 914 784 6205
  e-mail: [email-masked]

<[email-masked]>

10/06/2005 02:49 AM

To Chatschik Bisdikian/Watson/IBM@IBMUS
cc <[email-masked]>, <[email-masked]>, <[email-masked]>,
<[email-masked]>

Subject RE: Multicast in MPLS/BGP IP VPNs

Chatschik,

I fully agree with and support your reasoning and motivation to reduce
the number of options in the draft.

Regarding your proposal to select BGP as the mandatory option for
distributing multicast routing information, I agree that this has a
number of advantages. First of all, the ability to use the same
protocol for distributing customer unicast and multicast routing
information across the core supports functional convergence (which
offers a number of potential benefits, e.g. reduced complexity,
reductions in operating costs, etc.). Looking at the protocol itself,
the ability to use compartmentalised/dedicated MVPN RRs to minimise
the number of protocol sessions required and to scale the network
incrementally as the number of MVPNs increases is attractive. Also, as
you mention below, BGP has extensive policy controls and therefore is
an ideal protocol for supporting inter-provider MVPNs.

However, the questions that I would like to understand better are:

(1) Is it easier to solve the scaling issues associated with PIM and
to add things like inter-provider policy controls, or is it easier to
add multicast support to BGP?
(2) If PIM scaling wasn't an issue, would we still be discussing using
BGP anyway?

Regarding (1), I'm not a PIM or BGP expert so am unable to comment on
this myself. However, based on your email and talking to some of the
various MVPN draft authors, there are a number of people in the group
that think BGP is the best solution, particularly in the medium/long
term. In contrast, I haven't heard anyone say that they think we
shouldn't use BGP and that we should stick with PIM. Regarding (2), in
my opinion the answer is 'yes' due to the advantages mentioned such as
functional convergence, RR scaling and interprovider policy support.

Therefore, if there is agreement at this stage within the group that
the advantages of using BGP outweigh those of using PIM, then I
support your proposal to make BGP the mandatory option.

If this is the case, then as I said in my last email, looking at
things from an operators perspective, what would the migration path be
for providers that have already deployed MVPNs based on PIM/GRE? Would
it be a ships in the night only approach with incremental MVPN service
switchover, or could/should BGP-PIM interworking be supported?

Regards,
Richard
-----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of Chatschik Bisdikian
  Sent: 05 October 2005 18:52
  To: Spencer,R,Richard,XDE73 R
  Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
  Subject: RE: Multicast in MPLS/BGP IP VPNs

  Dear Richard,

  Thank you very much for your comments. First of all, we are in
agreement regarding your assessment of the maturity of the PIM
protocols. At the same time, we cannot argue against the collective
experience of protocol designers and implementers pointing towards
issues emanating from the "soft stateness/reliability" of these
protocols. While acknowledging the benefits of the latter design
choice (soft state), with increasing network sizes, the load that the
refresh of PIM state information creates the potential for severe
burdening of the compute and communication resources in the network.
This can be further exacerbated when join suppression cannot be
"activated" as is the case outlined in section 5.1.3 (unicast PIM
c-join/c-prune messages).

  Our aim is to reach as early as possible a simple baseline standard
design for the class of MPLS/BGP IP VPNs that contains as few
non-interoperable alternatives as possible and, hence, hasten the
creation of standards-based interoperable designs. The fact that
implementations of certain particular design choices may exist does
not necessarily establish a design precedence not deserving
reconsideration (and it is our understanding that you share a similar
view as well). Our note serves as a point of departure for one such
reconsideration.

  Our note proposes downplaying (and in the case of section 5.1.3 even
eliminating) those alternatives in the proposed draft that will be
dependent upon the standardization of additional solutions/procedures.
By selecting BGP as the baseline design choice, we leverage the
fundamental operational characteristics of the 2547 (unicast) VPNs,
operational characteristics that have been standardized long time ago
and fine-tuned ever since (e.g., using ORF to support P2P signaling,
as you suggest).

  Instead of waiting for the development (by which group(s)?) of
standardized solutions to issues like refresh reduction (an issue that
has remained unsolved in some time), this group could simply focus its
efforts in standardizing the format and meaning of the additional
information to be carried during the BGP control information exchanges
to support multicast VPNs; the draft already provides the collection
of the kind of information to be exchanged. We need to underscore here
that BGP will already be used for other operations in the multicast
VPNs, e.g., the autodiscovery process described in Section 4 of the
draft. So, it will make sense for the baseline design to leverage
further BGP, which will be an integral part of the final solution any
way.

  In summary, our proposal aims in reducing the number of operational
options in the final standard (and increase interoperability chances)
by leveraging those options for which standardized/parallel solutions
already exists (e.g., in the unicast BGP VPNs) and they will be
present in the final solution anyway (e.g., BGP for autodiscovery
purposes). I hope that this provides you with the motivational context
behind our proposal and answers your our points regarding BGP (our
preference) vs. PIM signalling within the P (core) network.

  Best Regards,

  Dr. Chatschik Bisdikian
  IBM T. J. Watson Research Center
  19 Skyline Drive, M/S 3S-B34
  Hawthorne, NY 10532, USA
  tel#: +1 914 784 7439
  fax#: +1 914 784 6205
  e-mail: [email-masked]

<[email-masked]>

09/28/2005 12:29 PM

To Chatschik Bisdikian/Watson/IBM@IBMUS, <[email-masked]>

cc <[email-masked]>, <[email-masked]>, <[email-masked]>

Subject RE: Multicast in MPLS/BGP IP VPNs

  Chatschik, John,

  In your email below you mention some of the advantages of using BGP
instead of PIM for PE-PE multicast routing, but you do not provide any
information regarding the advantages of using PIM instead of BGP, e.g.

  - PIM is a relatively mature protocol designed specifically for multicast
  - PIM based multicast VPN solutions are available today (and are
being deployed)
  - PIM supports P2P signalling between PEs for joins/leaves (whereas
BGP advertisements are broadcast based, although ORF can be used)

  I'm not saying that BGP isn't the way to go in the long term, in fact
I agree that it probably is. However, at this stage I think we need a
balanced understanding regarding the alternative approaches before we
can decide whether or not to remove certain options from the draft.

  At the last IETF meeting the PWE3 WG agreed that before deciding
whether LDP or RSVP-TE should be used for MS-PW signalling, it was
important to first determine exactly what changes would need to be
made to each protocol and to estimate what the impact of those changes
would be (i.e. major/minor). I think it would be worth performing a
similar exercise for BGP in order to understand exactly what changes
are required to support multicast and how significant those changes
will be, i.e. what problems need to be solved to make BGP do
everything (or a subset of what) PIM does and how easy/difficult are
those problems to solve. It would also be worthwhile looking at what
the issues are with PIM and how difficult those problems are to solve,
e.g. refresh reduction to improve scaling.

  If after looking at the tradeoffs it becomes obvious that BGP is the
way to go in the medium/long term, then from an operators perspective,
the two main things I would like to understand are:

  1) Realistically, how long will it be before the draft will be in a
state that will allow vendors to implement interoperable BGP based
multicast VPN solutions?
  2) What will the migration path to BGP be for providers that have
already deployed PIM based multicast solutions, i.e. will it be a
ships in the night only approach or should/could interworking be
supported, particularly in the inter-provider case?

  Regards,
  Richard
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of Chatschik Bisdikian
  Sent: 21 September 2005 19:03
  To: [email-masked]
  Cc: [email-masked]; [email-masked]; [email-masked]
  Subject: Multicast in MPLS/BGP IP VPNs

  Dear members of the l3vpn distribution list,

  The draft-ietf-l3vpn-2547bis-mcast-00.txt (May 2005) presents a new
framework and terminology to support multicasting over
provider-provisioned BGP/MPLS VPNs. The framework encompasses under a
common umbrella several options for MVPN control plane, data plane and
other relevant functions (many of these choices have been considered
on their own right in previous drafts).

  This note  focuses on PE-PE transmission of multicast routing
described in section 5 of the "2547bis-mcast" draft. We believe that
to achieve productive progress and increase interoperability chances
among products from different vendors that will support 2547bis-based
MVPNs, the number of alternatives in section 5 need to:

  a) Be reduced to a minimum number of possible alternatives, and
  b) Clearly spell out required and optional alternatives.

  Among the alternatives, we believe that BGP is the preferred
approach. BGP has the advantage of:

  - reliable transport;
  - established inter-provider operations;
  - a parallel operational model of the unicast 2547.

  The above *non-exhaustive* list provides benefits both in technical
terms (reliability) and in operational terms (exploiting/leveraging
established operational familiarity with the unicast 2547 case).
Using the PIM alternatives in section 5, both multicast or unicast,
does not provide any of these advantages -- section 5.1 (PIM peering)
points out that the periodic refresh of PIM C-Join/Prune messages
(which is done to provide a level of reliability for PIM)
disadvantages the PE routers.

  We therefore propose to elect BGP as the required way to carry
multicast routing information between PEs as described in section 5.2
of the draft and, at a minimum, we propose the elimination of section
5.1.3 (Unicasting of PIM C-Join/Prune messages).

  Regards,

  Chatschik Bisdikian
  IBM T. J. Watson Research Center

  John E. Drake
  Boeing Satellite Systems

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

------ End of Forwarded Message

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Rurick Kellermann <[email-masked]>
Date: Wed, 19 Oct 2005 09:40:22 -0400

Nidhi et all,

I agree with your statement about the maturity of PIM-SM. However,
believe it or not, the idea of using MP-BGP with extensions instead of
PIM is taken seriously by the L3-VPN group.

I follow both WG emails - there's perception in the L3-VPN WG that
there are a lot of shortcomings on PIM-SM. Perhaps we should invite
for a more detailed discussion about it, or rather, shouldn't this WG
add it to the chart?

---

From: Beau Williamson <[email-masked]>
Date: Wed, 19 Oct 2005 10:14:26 -0500

At 10/19/2005 08:40 AM, Rurick Kellermann wrote:
>there are a lot of shortcomings on PIM-SM.

Got any pointers to specifics about these perceived shortcomings?

I suspect they are most concerned with the fact that it uses soft-state 
which has to be refreshed but I'm just guessing.

Beau

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 19 Oct 2005 11:51:27 -0400

The L3-VPN problem is a subset of the more general PIM multicast
routing problem. But they have fore knowledge that they can use to
their advantage that PIM alone doesn't have. For instance, they
already know their PIM neighbors and they know the best egress point
to reach sources.

They are having scaling problems with the current PIM soft-state
design.  These scaling problems are actually a general PIM problem
and so we thought we would try to solve them in a general way and
they could benefit from this. However, we are on two different time
scales. They have deployment problems today and the general PIM
deployment outside of L3-VPNs does not.

We have started the pim state refresh reduction work which could
help them but there isn't consensus on how this should be done and
forward progress has been slow. This also doesn't solve their problem
of hello traffic.

Therefore, it makes perfect sense for them to solve their problems
now instead of waiting for us. They don't need hellos, they already
are talking to the routers they want to and have established BGP/MPLS
state.

I think this will be a great discussion topic in Vancouver. I'll
put it on the agenda and be sure to invite those from L3-VPN.

If we don't want them to do everything with BGP, then we need to
provide them an alternative. But that means getting something
finished and getting it implemented.

Thanks,
Tom

---

From: Yiqun Cai <[email-masked]>
Date: Wed, 19 Oct 2005 09:43:55 -0700

> deployment outside of L3-VPNs does not.

Tom,

A little bit of different opinion here.

I'm not convinced that the problems we face today in MVPN deployment  
are all due to limitations existing in PIM.  IMO, implementation  
shortcomings play a more significant role in today's deployment.

> are talking to the routers they want to and have established BGP/MPLS

There are two aspects as you point out.  One is the elimination of  
Hellos.  The other is the elimination of periodic Join/Prunes.  The  
first doesn't really require a whole sale change in PIM or BGP.  The  
second,  which has been debated, is certainly a good topic for us to  
discuss in Vancouver. I think the expertise we have in building  
multicast trees will certainly be helpful in guiding whatever design  
that is coming.

Thanks.

--
Yiqun

---

From: "Suresh Boddapati" <[email-masked]>
Date: Wed, 19 Oct 2005 10:30:02 -0700

> forward progress has been slow.

Tom,
The last time I checked with Dino, it seemed like the refresh reduction
work was not necessary since there were other mVpn problems (??) which
would still be there even if refresh reduction was done. If refresh
reduction is THE problem, then I think we can work on getting a
consensus and solve it. There are couple of solutions which have been
discussed in detail and getting them down to one should not be a
problem. 

Suresh

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Oct 2005 11:07:05 -0700

>> PIM is taken seriously by the L3-VPN group.

    That, in and of itself doesn't make it the right technical direction.

>> for a more detailed discussion about it, or rather, shouldn't this WG

    Did people ever consider that a periodic message infrastructure in a
    protocol has a lot of benefits for a modular protocol implementation?
    
    Do people realize there doesn't need to be any protocol graceful restart 
    mechanisms in PIM, IGMP, and MSDP because they are not needed. This allows
    customers to upgrade a single protocol without taking the whole system
    down.

    I'm not saying this can't be done with MP-BGP but having a periodic
    infrastructure does add a level robustness and simplicity in the 
    implementation design of protocols. And this is important because it 
    translates to a more stable product.

    And at the end of the day, the most important delieverable a network needs
    is stability first and features second.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Oct 2005 12:12:49 -0700

Cc'ing l3vpn working group.

>> already know their PIM neighbors and they know the best egress point

    There are scaling problems with basic PE-based VPNs. How do you expect
    anything that overlays on top of it to work well?

    PE-based VPNs will not scale, it is the wrong place to put the technology.
    Putting VPN support at the edges (CE-based VPNs) allows them to scale in a
    distributed manner and is more cost-effective because you can avoid the 
    huge honkin PE box cost with all sorts of additional issues like lack of 
    privacy, single point of failure, etc...

    People say that CE-based VPNs are too hard to manage by a service provider.
    I don't believe it for one minute. If cable and DSL providers can put
    boxes in our homes, we can have script-based or auto-configuring CE-based
    devices in remote offices. And if and only if you want network based
    encryption, then you get encrypted packets starting out on the CE-PE link.

    So let's fix the fundamental problem and not finger point to PIM or any
    other protocol. BTW, we could get BGP to scale better too if it didn't 
    have to support VPNs.

Dino

P.S. Tom, I am not picking on you. It was just your email that invoked my
     response. There is nothing you said that I necessarily disgree with.

-------------------------------------------------------------------------------

To: Beau Williamson <[email-masked]>
Subject: Re: [pim] Fwd: Multicast in MPLS/BGP IP VPNs 
Date: Wed, 19 Oct 2005 11:51:27 -0400
From: Tom Pusateri <[email-masked]>
Cc: Nidhi Bhaskar <[email-masked]>, [email-masked], [email-masked],
        [email-masked]
Sender: [email-masked]

Thanks,
Tom

-------------------------------------------------------------------------------

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Oct 2005 12:25:43 -0700

>> work was not necessary since there were other mVpn problems (??) which

    Yep, that pretty much sums it up. And of course, how much of a change this
    would be to the PIM protocol. What most people seemed to agree on is if 
    there were going to be changes that they would go into a PIM version 3.

    But since we somewhat are stuck with PE-based VPNs and if the periodic 
    problem with PIM JP messages is really affecting real network deployment, 
    I would like to go with a more simplicistic approach than the JP-Ack
    proposal sent to the list this past spring.

    I was wondering if we could use FEC technology to make triggered JPs
    more reliable and simply back-off the periodic transmissions to say
    10 minutes (purely for database sanity synchronization).

    I know there are many people that have deep experience in this area on
    this list. Just brainstorming...

DIno

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 19 Oct 2005 17:04:42 -0400

>    proposal sent to the list this past spring.

I too think the JP-Ack proposal that went around is too complex. Initially,
I thought that maybe we could do something similar to OSPF only on a
link-local basis. Treat it as a link-local state flooding problem. But
then I remember how long it took for everyone to get that working right.

People got MSDP up and running very quickly. So maybe its better to go
with a TCP approach. You could elect a DR then form a TCP connection with
the DR and reliably send the join information that way. I bet Dino
could make the changes in a weekend (the rest of us might take a week or so!).

>    10 minutes (purely for database sanity synchronization).

FEC helps deal with the problem of corrupted or missing data in a packet
but not so much with the problem of lost packets. You'll need some sequence
number or database synchronization field to detect these and that means
either the Ack approach or the OSPF-like database identifier approach.

>    this list. Just brainstorming...

Yep. good idea.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Oct 2005 14:41:05 -0700

>> then I remember how long it took for everyone to get that working right.

    Right.

>> could make the changes in a weekend (the rest of us might take a week or so!).

    But this has all the disadvantages that route reflectors do in BGP.

>> but not so much with the problem of lost packets. You'll need some sequence

    It can deal with lost packets in a batch. Where the batch has redundancy
    codes embeeded.

>> either the Ack approach or the OSPF-like database identifier approach.

    Right. Or Hellos which are smaller and not as bursty as a set of JP
    messages.

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 20 Oct 2005 06:25:03 -0700

Dino,

>     There are scaling problems with basic PE-based VPNs. 

Perhaps you could elaborate on the scaling problems with *basic*
(means multicast not included) PE-based VPNs.

>     How do you expect anything that overlays on top of it to work well?
> 

Do you have facts to support your claim that "PE-based VPNs will not
scale", or is it proved by an emphatic assertion ? 

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 20 Oct 2005 06:58:19 -0700

Dino,

>     That, in and of itself doesn't make it the right technical direction.

And neither the maturity of PIM-SM.

>     protocol has a lot of benefits for a modular protocol implementation?

Yes, people did consider this. And more than once, based on the
*operational experience* they decided that this is should be avoided.

Just consider EGP2. It is precisely the experience that resulted
in replacing periodic EGP2 Updates with incremental BGP updates
that are carried over a reliable transport.

And if that is not enough, then consider original RSVP (with no
scalability enhancements, like refresh reduction).  Again, it is
precisely the experience that resulted in adding all the scalability
enhancements to RSVP (like refresh reduction).

>     customers to upgrade a single protocol without taking the whole system

Since you claim that PIM "allows customers to upgrade a single protocol 
without taking the whole system down", and since you work at cisco
please tell us how one could upgrade PIM in cisco IOS classic without 
taking the whole IOS down.

>     translates to a more stable product.

And it also adds an overhead to the control plane. And once the 
control plane is overloaded, such things as "simplicity in the
implemenation design of protocols" matters very little.

>     is stability first and features second.

Follow your line of reasoning we should just stick with static
routing, as static routing is certainly more stable than any form
of dynamic routing. 

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Oct 2005 09:10:42 -0700

>> scale", or is it proved by an emphatic assertion ? 

    There is tons of literature about this. You just have to read it with an
    open mind.

>> taking the whole IOS down.

    In a modular system, it is possible. Cisco has more than one operating
    system so it is possible in some products. But why are we talking about
    cisco here.

>> implemenation design of protocols" matters very little.

    Tell me the BGP control-plane is not overloaded? I would agree with your
    assertions but you are not consistent.

>> routing, as static routing is certainly more stable than any form

    I wouldn't go that far. But I do remember a quote from a colleague (one
    I do respect -- that would be you!) once said:

        "The best routing is static routing since there are no route flaps"

Dino

---

From: Nidhi Bhaskar <[email-masked]>
Date: Thu, 20 Oct 2005 09:23:44 -0700 (PDT)

Hi, all,

Good to see this topic getting some airtime here...

o Having a presentation from L3VPN folks in PIM WG would be
   great. What would this cover, requirements for PIM or why they propose
   BGP is the way forward ?

   On the PIM side, PIM Hello suppression is trivial. J/P refresh
   reduction is more work, but not overly complex. Would be good to
   hear about what "other stuff" PIM cannot provide.

o Regardless of which protocol is used for PE-PE signaling, the PIM-WG
   needs to be involved. As there will be a need for PIM state machine
   changes on the edge.

   I.e. on replacing PIM Lan procedures with this new PE-PE signaling
   protocol - it isn't clear that all PIM messages sent on the "LAN" can
   be mapped into this new signaling protocol.

o And if the protocol for carrying multicast routing ends up being
   BGP, then we need to define the state machine between PIM and
   BGP... At this point we are not in well understood territory.

>    But this has all the disadvantages that route reflectors do in BGP.

Well it doesn't if we don't use the route reflectors :).

We can mitigate the # of TCP sessions by keeping up sessions only with
PEs to which we need to send messages. PIM (unlike BGP) doesn't need
to send j/p information to all other PEs in the VPN, only to the PE
which is the "RPF/Upstream" PE. We can mitigate this further by only
creating TCP sessions with PE/ASBRs in the same AS.

BTW, having spent some time looking into what it takes to do this with
BGP - I think a BGP based proposal is certainly not a simple "cookie
cutter" SAFI extension. So I do worry about how long it'll take to get
that right.

Someone suggested (on the forwarded thread) that some analysis of what
it takes in PIM vs BGP should be done before a decision can be reached
- and I agree.

Thanks,
Nidhi.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Oct 2005 10:03:31 -0700

>> Well it doesn't if we don't use the route reflectors :).

    The approach Tom suggested would require the DR to aggregate all 
    connections from each router on a LAN. Then the DR would have to  
    redistribute the data it received on one connection to all other
    connections on the LAN.

    We still have to assume Join-override and Join-suppression logic might be
    in effect on the LAN so all routers on the LAN need to get the JP message.

    Remember, Tom's suggestion was to make a very small change so we have to
    assume nothing else in the PIM protocol machinery changes.

>> creating TCP sessions with PE/ASBRs in the same AS.

    So this would be a PE-only solution and you wouldn't use TCP for the
    general PIM case on LANs and point-to-point links? Is that what you are
    saying?

>> cutter" SAFI extension. So I do worry about how long it'll take to get

    Right, all forms of SSM, ASM, and possibly Bidir might have to be 
    supported in BGP. This would certainly merit BGPv5 versus PIMv3. That is,
    pretty much a new multicast routing protocol design in BGP (i.e. BGPv5)
    or adding reliability to PIM (i.e. PIMv3).

    Large architectural changes to either protocol.

>> it takes in PIM vs BGP should be done before a decision can be reached

    Definitely.

Dino

---

From: Nidhi Bhaskar <[email-masked]>
Date: Thu, 20 Oct 2005 10:58:59 -0700 (PDT)

>    assume nothing else in the PIM protocol machinery changes.

Ah, I see. I missed that. I wasn't thinking along the lines of a DR
doing this. Rather to use TCP sessions with neighbors that you want to
send messages to. We would rely on explicit tracking to prune the tree
and there would be no join suppression.

>    general PIM case on LANs and point-to-point links? Is that what you are

I think we can focus the effort on PE-only solution to begin with. And
then see what it takes to use it on a LAN/p2p link. I don't think
one precludes the other...

Nidhi.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Oct 2005 12:30:05 -0700

>> and there would be no join suppression.

    You mean PE-to-PE? Yes agree.

>> one precludes the other...

    Right but I hope it doesn't force us into 2 different methods. That is
    usually the case.

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 20 Oct 2005 13:28:18 -0700

Dino,

>     There is tons of literature about this. You just have to read it with an

How about instead of "tons of literature" just present the actual
facts ?

Please also look *with an open mind* at Section 15 of 
draft-ietf-l3vpn-rfc2547bis, as this section present scalability analysis 
of 2547 VPNs.

>         "The best routing is static routing since there are no route flaps"

You probably did not get the bottom line - it was a joke.

Yakov.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 25 Oct 2005 14:01:52 -0400

Hello;

<massive snip!>

> >> it takes in PIM vs BGP should be done before a decision can be reached

I strongly agree with this and would be willing to donate my time  to
help make this
happen. Any other volunteers ? I think that a start would be to
summarize the existing
draft and this thread, and at least try and get the issues down on paper.

Regards
Marshall Eubanks

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 28 Oct 2005 08:21:27 -0400

I have gotten responses from  a few people, and have now  set up a mailing  list
devoted to this. Details are at

http://www.multicasttech.com/L3VPN-Multicast/mail_list.html

Regards
Marshall Eubanks