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

[Toerless Eckert <eckert at cisco.com>]

On Thu, May 20, 2004 at 10:41:35AM +0300, Pekka Savola wrote:
> Sorry for missing the LC DL a bit. A couple of observations.

There must be a hibernation virus going around... ;-))

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

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)

(And being so critical against the multicast protocols not providing
 good motivational architecture drafts, i have to also mention that other 
 groups in the IETF are not much better, they just sometimes make money by
 writing books about the background of their protocols *hint* *hint* ;-))

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

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

>   b) if the group has been configured as bidir, instead of  
>      encapsulating, just send it over towards the RP.

"over towards RP" - please explain.

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

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

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

Bidir-PIM works fine as it is defined for domains where you can have
consistent RP mapping and it does fill in its current form an important
role in providing scalability for multi-source enterprise ASM applications.
Expanding bidirectional (*,G) only trees beyond this is definitely an
entertaining engineering topic, but it would not invalidate the current
Bidir-PIM design because even if we may be able to get rid of DF election,
we will be creating some other form of complexity/downside. So right
now Bidir-PIM is understood to be only applicable to a single coordinated
administrative domain or group of domains.

In addition to protocol complexity, it is completely questionable how much
more than engineering curiosity will be satisfied with for example a better
Internet-wide ASM model through whatever Bidir-PIMv2 we might want to design:

As i think i said more than once: Who the heck would want to use ASM service
across an Internet where 5 million users can blast traffic into your group ?
Yes, in something like 6NET or even I2 or other IPv4 multicast deployments
you might be able to safely use ASM, but also only because not every single
PC of every single consumer is connected to it.

As long as (partially interdomain) networks stay this way, ASM has value,
but for such networks you could also still pretty well administer
coordination for existing Bidir-PIM domains if there was a strong enough
need for it.


So, in summary:
  - Bidir-PIMv1 fills a need in enterprises, it works, it should go forward.
  - Bidir-PIM for larger scopes is an interesting engineering exercise,
    but it has not yet proven to be in strong demand, and it is unclear
    what largest scope it would make sense for anyhow before the
    security issues of the ASM service model would become overwhelming.
    Likely the range of scopes for such a larger scope Bidir will be limited.

I'll let the details questions below be answered from someone
from the spec writers team.

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