Re: [pim] WG Last Call - draft-ietf-pim-bidir-06

[Stig Venaas <Stig.Venaas at uninett.no>]

On Sat, May 22, 2004 at 07:54:44AM +0300, Pekka Savola wrote:
> On Thu, 20 May 2004, Toerless Eckert wrote:
> > On Thu, May 20, 2004 at 10:41:35AM +0300, Pekka Savola wrote:
[...]
> > > But the spec also includes e.g. DF election procedures (11 pages).
> > 
> > WHich is kinda the core of Bidir-PIM, ensuring the fast and loop-free
> > creation of the crucial upstream forwarding part of the tree.
> 
> This is my main gripe, I think.
> 
> If you want to make PIM-SM DR election faster, why not improve DR 
> election, instead of inventing a new protocol which does N+1 other 
> things as well.

But you don't want a "random" router on the link to have the role of
the DF. You can't just use the DR selection algorithm. You want to
know which router has the best route to the RPA.

> Couldn't all of these be achieved by modular PIM-SM enhancements
> (killing the registers, faster convergence, adding IGP metrics, ...) ?
>  
> > > AFAICS, what you could do is just specify that:
> > >   a) DF is automatically elected the same way as DR, but just among 
> > >      those DRs which are bidir-capable.  Code reuse and 
> > >      simplification.  Why should different DF's be used for different
> > >      groups?  This way it works for embedded-RP as well.
> > 
> > A bidirectional spanning tree for a group has to be rooted in the RP.
> > See also SPT protocols at L2 ;-). That's why DF election has to be per DF.
> 
> Perhaps you meant 'per group' not 'per DF'.

Per RPA I think.

> So, you have an implicit assumption that you have important scenarios 
> where there are multiple multicast routers attached to receiver/sender 
> LANs, and those different multicast routers serve different groups?
> 
> Is this really a relevant scenario? 
>  
> Even if so, note that actually you don't need DF election per group,
> but per group-to-RP mapping, right?  With such a change, it would work
> for embedded-RP as well I think.

On many links you will have at least two routers, and for each RPA you
want to know which of them has the best path. Which group is involved
is not all that interesting.

> > >   b) if the group has been configured as bidir, instead of  
> > >      encapsulating, just send it over towards the RP.
> > 
> > "over towards RP" - please explain.
> 
> The bidir PIM data forwarding algorithm appears to be basically 'punt
> the data out on the interface which is the best neighbor towards the
> RP'.  There is no magic in this.  Could be done with PIM-SM if the
> routers would just learn that it's safe to do so (i.e., that the
> routers on the path all supported this data forwarding).

But you have the problem of avoiding loops and knowing which direction
the data should be forwarded. I think this gets tricky, at least with
more than two routers on a link.

[...]
> However, I don't quite understand why doing DF election avoids this
> particular problem?
> 
> One clarification: when the packets go to the RP, and the RP sends
> them back, are the packets stamped with RP's IP address, or the
> original senders'?  I guess it's the original. (Otherwise, you could
> use the RP addresses to distinguish up/downstreams.)

Yes

> Isn't it sufficient to just check that if the packet came from iif
> that points toward the RP, it's a downstream packet, and if it came
> from somewhere else (provided that the direction is RPF-wise correct),
> it's an upstream packet?

Not if you have three routers on a link.

[...]
> But that's not the point.  You'll have to have a data-driven even in
> any case, I think.  How can you elect a DF for a group which you don't
> know a host will be creating before the group has been created by
> sending to it?  E.g., if you specify that 239.2.0.0/16 is bidir, and a
> source-only host starts sending to 239.2.2.2, you don't know that
> before the data has been sent, and you have to snoop the data to know
> it -- making it a data-driven event!?

Before any host does anything, all the routers learn about
239.2.0.0/16 and the RPA for it, and the DF-election is all done
(hopefully) before the host starts sending. There is no event
when the source starts, it's just forwarding. There's no per source,
and not per group state either in source-only branches.

Stig

PS I'm supposed to be on holiday, leaving RSN, just couldn't resist
   sending a last mail.

_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim