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

From: Pekka Savola <[email-masked]>
Date: Tue, 11 May 2004 12:51:07 +0300 (EEST)

Hi,

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.

There was a lengthy discussion at MBONED how Bidir could or could not 
be modified to support Embedded-RP (and the feasibility of different 
approaches).

I'd like to get an explicit feel what people in this WG think we
should do with regard to the bidir-PIM spec:
 
 1) try to figure out (at least some of) the details of 
    embedded-RP now,

 2) try to work on this later, if necessary (with the caveat that then 
    modifications might be difficult or impossible as they'd have to 
    be backward-compatible), or

 3) do something else, what?

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 May 2004 12:51:07 +0300 (EEST)

Hi,

---

From: Mike McBride <[email-masked]>
Date: Tue, 11 May 2004 10:18:06 -0700 (PDT)

Pekka,

>  3) do something else, what?

2/3) How about a new bidir w/embedded RP or bidirv2 type draft is
written. And we allow this -06 to proceed.

thanks,
mike

---

From: Mike McBride <[email-masked]>
Date: Tue, 11 May 2004 10:18:06 -0700 (PDT)

Pekka,

thanks,
mike

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 May 2004 16:21:03 -0700

>>     be backward-compatible), or

    I vote for this.

Dino

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 11 May 2004 16:23:30 -0700

I agree with Mike that we should not try to modify the current
specification to include embedded-RP functionality and we should
address this in a separate (possibly non backward compatible) revision
if necessary. The current specification has been fairly stable for a
while and reflects at least 2 shipping implementations.

Isidor

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 May 2004 16:21:03 -0700

I vote for this.

Dino

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 11 May 2004 16:23:30 -0700

Isidor

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 May 2004 10:41:35 +0300 (EEST)

On Wed, 28 Apr 2004, Mike McBride wrote:
> 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.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 May 2004 10:41:35 +0300 (EEST)

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

...

RP-Address

....

4.  RP Discovery

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 20 May 2004 08:06:06 -0700

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

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

> Major comment fundamental comment:

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* ;-))

>    register-encapsulation towards the RP, for groups supported by 

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.

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

>      encapsulating, just send it over towards the RP.

"over towards RP" - please explain.

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

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

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 20 May 2004 08:06:06 -0700

So, in summary:

---

From: Isidor Kouvelas <[email-masked]>
Date: Fri, 21 May 2004 16:53:50 -0700

Pekka Savola writes:

I have skipped the "Major comment" to which I think Toerless gave a
good response.

>More minor comments:

HIIIII!!!!! HOW ARE YOU?!?!?!?!?!
First of all there is no incremental deployment for BIDIR-PIM.  Mixing
BIDIR capable and legacy routers in a domain is a mis-config which the
option helps detect. Obviously if on a BIDIR capable router you have
BIDIR PIM disabled then you will not see such a message because you
have a non capable neighbour.
Now it is true that the option itself dates back to Dino's draft that
did specify incremental deployment. The main reason we cannot remove it
now is to keep existing code happy.

>try to use bidir forwarding algorithm towards the neighbor, and it 

There is currently no way of knowing what the group to RP / protocol
mapping is on a neighbouring PIM router. The assumption is that if the
neighbour is BIDIR capable then it has made the same interpretation of
the config / BSR advertisement.

>==> IPv6 support, anyone?

Someone. Some of the v6 mods went into the current PIM-SM spec after I
pulled a lot of the text for Bidir. I guess we have missed some stuff
that changed since. We will go through PIM-SM to see what applies.

>MSDP, but it would not hurt to spell it out.

It does not "just work". We scoped the mods at one point in time to
see what would be required. There are significant changes to make
source-only branches traverse a BIDIR domain.

>Encoded-Group Address (this isn't yet reflected in the bsr spec).

It was in the BIDIR spec but I pulled it out and handed the text over
to the BSR authors for inclusion in the next version of that spec.

>the routers per interfaces, and is completely unrealistic.

I am sorry that this is so "totally bogus". I think this text was
again lifted from PIM-SM. We will update to match the current version.

Isidor

---

From: Isidor Kouvelas <[email-masked]>
Date: Fri, 21 May 2004 16:53:50 -0700

Pekka Savola writes:

Isidor

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 May 2004 06:51:17 +0300 (EEST)

Sorry if I sounded a bit aggressive in my comments .. :)

> now is to keep existing code happy.

Sorry, what I meant is incremental _router software_ deployment.

In a network of 100 multicast routers, this implies either that:
 a) bidir-pim must always be disabled by default, or
 b) all the routers must be upgraded simultaneously.

If I'm not misunderstanding something, bidir-pim could be enabled by 
default (but not active until a group advertisement with bidir flag is 
sent) by a slightly different strategy .. see below.

> the config / BSR advertisement.

I fail to see why this is relevant. The routers could stay "dormant", 
advertising bidir-pim capabilities but not using bidir-pim for 
anything until such time that config/BSR advertisement decrees that 
bidir-pim is to be used for a group, right?  Or is there something I'm 
missing?

When you get that BSR advertisement, only *then* you should start 
complaining if your neighbors aren't bidir-PIM -capable.
 
> source-only branches traverse a BIDIR domain.

So it should be spelled out I think..

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 May 2004 06:51:17 +0300 (EEST)

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 May 2004 07:54:44 +0300 (EEST)

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

>  (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?"
 
> 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, ...) ?
 
> 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.

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

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

> 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.
 
> PIM link-layer packets "control-plane-packets" - so it's not a data-triggered

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

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 May 2004 07:54:44 +0300 (EEST)

No such draft there.

---

From: Stig Venaas <[email-masked]>
Date: Sat, 22 May 2004 08:03:57 +0200

On Sat, May 22, 2004 at 06:51:17AM +0300, Pekka Savola wrote:
[...]
> On Fri, 21 May 2004, Isidor Kouvelas wrote:
[...]
> > now is to keep existing code happy.

It should, I hope, be possible to deploy bidir in a scoped zone, and
have pim-sm in surrounding routers outside the zone where the bidir
routers are used for groups belonging to the scope inside the zone.

At least I think so, and I think that's a realistic scenario.

> complaining if your neighbors aren't bidir-PIM -capable.

And only if they are inside the zone I think. If you learn of say an
bidir RP for 239/8, don't complain about router outside 239/8 not
doing bidir.

I think such logging need to be optional though.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Sat, 22 May 2004 08:03:57 +0200

[...]

Stig

---

From: Stig Venaas <[email-masked]>
Date: Sat, 22 May 2004 08:22:34 +0200

[...]
> election, instead of inventing a new protocol which does N+1 other 

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.

> Perhaps you meant 'per group' not 'per DF'.

Per RPA I think.

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

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

[...]
> use the RP addresses to distinguish up/downstreams.)

Yes

> from somewhere else (provided that the direction is RPF-wise correct),

Not if you have three routers on a link.

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

---

From: Stig Venaas <[email-masked]>
Date: Sat, 22 May 2004 08:22:34 +0200

[...]

Per RPA I think.

[...]

Yes

[...]

Stig