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

[Pekka Savola <pekkas at netcore.fi>]

On Wed, 28 Apr 2004, Mike McBride wrote:
> Today begins a Working Group Last Call for the Bi-Directional PIM
> Specification. The Last Call runs 2 weeks from Wednesday, April 28th, 2004
> to Wednesday, May 12th, 2004.
> 
> Please review this document and send comments either to the list or
> directly to the authors.

Sorry for missing the LC DL a bit. A couple of observations.

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

But the spec also includes e.g. DF election procedures (11 pages).

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.
  b) if the group has been configured as bidir, instead of  
     encapsulating, just send it over towards the RP.
  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. 
  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.

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

More minor comments:
--------------------

Bidir PIM introduces the Bidir_Capable PIM-Hello option that MUST be
included in all Hello messages from a Bidir-PIM capable router.  The
Bidir_Capable option advertises the router's ability to participate in
the Bidir-PIM protocol. The format of the Bidir_Capable option is
described in section 3.7.

==> HELLO?!?!!?!?  Do you mean that every router in a domain that is
bidir-capable starts logging errors about every neighbor they have
which is not bidir-capable?!??  Say goodbye to incremental deployment 
and adding bidir capability on by default!

The warning is should probably something that should be activated if a 
group has been configured as bidir, but your neighbor isn't, or if you 
try to use bidir forwarding algorithm towards the neighbor, and it 
isn't bidir-capable.

...

If instead the administrator chooses to configure the RPA to be the
address of an interface of a specific router then nothing changes.

==> s/an interface/a physical interface/ ?  
==> fwiw, this section is IMHO quite confusing and pretty much 

BIDIR-PIM messages are multicast with TTL 1 to the `ALL-PIM-ROUTERS'
group `224.0.0.13'.

==> IPv6 support, anyone?

RP-Address
     The bidir RPA for which the election is taking place (note that the
     length of this field is more than 32 bits).

==> the point of the bit-wise diagrams is that they are accurate.  If 
it isn't 32 bits, change it accordingly!  The figures aren't just 
listing which fields come after another, but describing where one 
ends and the another begins.

....

4.  RP Discovery

Routers discover that a range of multicast group addresses operates in
bi-directional mode and the address of the Rendezvous-Point address
(RPA) serving the group range either through static configuration or
using an automatic RP discovery mechanism like the PIM Bootsrtap
mechanism (BSR).  [9] or Auto-RP.

==> what is the BIDIR interdomain strategy?  There's no need for such, 
I think, because it'll "just work the same way as PIM-SM" if you use 
MSDP, but it would not hurt to spell it out.

==> s/BSR). /BSR)/, s/Bootsrtap/Bootstrap/

==> It would be worth stating (because it's not obvious) that the BSR 
discovery works by the RP setting the bidir-capable bit in the 
Encoded-Group Address (this isn't yet reflected in the bsr spec).

5.3.  Authentication Using IPsec

The IPsec [5] transport mode using the Authentication Header (AH) is 
the RECOMMENDED method to prevent the above attacks against BIDIR-PIM.

It is RECOMMENDED that IPsec authentication be applied to all 
BIDIR-PIM protocol messages.

==> this is totally bogus recommendation, and luckily enough the 
PIM-SM spec uses only MAY.  This would require manual key config on 
the routers per interfaces, and is completely unrealistic.


editorials:
-----------

     This document discusses Bi-directional PIM, a variant of PIM
     Sparse-Mode [4] that builds bi-directional shared trees

==> no refs in the abstract.

"OPTIONAL" are to be interpreted as described in RFC 2119 and indicate

==> maybe should add an explicit ref to 2119.

In this respect BIDIR-PIM differs from PIM-SM that
      requires an actual router to be configured as the Rendezvous Point
      (RP).

==> that requires --> that _it_ requires?  however this is not clear 
whether "it" would refer to bidir of pim-sm.

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