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

[Pekka Savola <pekkas at netcore.fi>]

On Thu, 20 May 2004, Toerless Eckert wrote:
> On Thu, May 20, 2004 at 10:41:35AM +0300, Pekka Savola wrote:
> > Major comment fundamental comment:
> > ----------------------------------
> > 
> > I fail to see the high-level justification for this approach, perhaps
> > a more extensive "Protocol Overview" would be called for if I've
> > misunderstood something.
> > 
> > Basically, I don't see what it is that requires 45 pages of
> > specification and new mechanisms which weren't available in PIM-SM!  
> 
> Protocol architecture and motivation drafts are also what i am always
> asking for, but there doesn't seem to be too much of an interest in the
> IETF to write them. Likely they can also be controversial and they
> are probably also not easy to write.

In most cases, some of this is included in the specifications 
themselves.  There's a short section even in PIM-SM spec, though not 
really a lengthy one.

> I don't think it is fair to bring up this point against the Bidir-PIM
> draft, because i think none of the multicast protocols so far has had
> any such companion documents or larger parts of the protocol spec
> reserved for such motivational talk. If you want to contribute to the
> process, i would propose you pick up the PIM architecture draft,
> that ran from 1994 to i think 1998 and was then silently killed because
> everybody who worked on it got bored (i guess). I only have a version
> from 1999 lying around, but i think i once tracked it up to 1998 on some
> ftp servers on the internet.
>  (ftp://ftpeng.cisco.com/ipmulticast/drafts/pimv1-arch.txt)

No such draft there.

What I'm looking for is the answer to questions like:
 - "what are the functions of the protocol?  what problems is it 
intended to solve and how it does that?"
 - "why this is the correct approach to solving these problems?"
 
> > The fundamental function of bidir-PIM appears to be:
> >  
> >    Forwarding packets from the adjacent links without 
> >    register-encapsulation towards the RP, for groups supported by 
> >    bidir-PIM.
> 
> Not really, it's more like the "establish and fast-converge of
> loop-free rp-rooted bidirectional spanning trees within a network" function.
> 
> > 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.

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'.

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.

> >   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).

> >   c) if the group has been configured as bidir, the routers along the 
> >      path are expected to be bidir-capable.  The only change they need 
> >      is to (if I'm not mistaken) is to add the RP address for all 
> >      groups G to their olist, i.e., pass the data packets towards the 
> >      RP if they come from the right direction. 
> 
> Yeah, well if it was just that simple.  The problem is really in
> differentiation upstream vs. downstream traffic to avoid loops if you try
> to avoid DF election.
> 
> We've been circling around lots of options to simplify the design and
> get away from DF election - so as to be able to easier support
> embedded-RP with Bidir-PIM, but the problem is that to avoid possible
> loops you then have to well know whether you're sending upstream or
> downstream. There are a couple of options on how to do this, one
> was Dino's original UMP option in the IP header (set only for upstream,
> then cleared), which is not too cool as long as there are still vendors
> with ASIC driven HW forwarding (sigh), and the other option is to
> differentiate based on L2 information, eg: upstream forwarding uses
> for example unicast encap and downstream forwarding multicast, but this
> falls flat when you have an L2 that doesn't have unicast/multicast
> differentiation - like POS (you don't know whether the packet is up or
> downstream). Not to speak of ASIC HW forwarding that wouldn't know
> L2 encap anymore when it's doing L3 lookup.

This problem should have ended up in the spec :).

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.)

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?

> >   d) if you'd send a packet to a router using bidir mechanisms but it 
> >      doesn't advertise to be bidir-capable with hellos, log an error.
> 
> Data-triggered-event ? That's about the time when the Bidir-Philosophy
> Enforcement team (in the person of Isidor) would come to claim your head.
> 
> Yes, if we introduce some form of data triggered events we can also have
> some other workaround for the problem.

OK, you can make this control-plane triggered event as well, by
checking that when a group w/ bidir appears in BSR or config, require
that all neighbors support bidir.
 
> >    15 pages of very simple spec, and this would also work for embedded 
> >    RP.
> > 
> > Could someone please enlighten me what is the justification behind the 
> > current design?  I see that killing data encap/decap is important, but 
> > I fail to see the need for this way too complex approach.
> > 
> > I guess the reason here is "no data driven events", but I can't see
> > how this applies, as DF election is also a data-driven event
> > (something must trigger the election to happen for a specific group --
> > for example if there is no group-specific state and the first thing to
> > a new group is a sender-only branch).
> 
> Yes, well, that's why they call DF-election packets like all other
> PIM link-layer packets "control-plane-packets" - so it's not a data-triggered
> event.

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!?
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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