Subject: [pim] San Francisco PIM WG meeting minutes

From: Liming Wei <[email-masked]>
Date: Tue, 18 Mar 2003 18:00:25 -0800 (PST)

Folks,

We forgot to ask for a volunteer to take notes. Here is a note
I typed quickly while my memory is still fresh. Additions/updates
are welcome.

Working group: PIM
Location: San Francisco Hilton
Time:  3/18/2003, 3:45pm
Note Taker: Liming Wei

1. Hugh did an update on PIM SM spec. Updated the security section
   of draft. (*,*,RP) will stay in spec, for future use, to fix up
   one problem involving (S,G)RPT prune.
2. Mark Handley on PIM BSR flooding problem on LANs with inconsistent
   RPF information across different routers.
   Change of rule is to forward BSM out all interfaces including
   the RPF interface where the BSM was received on.
3. Dino presented proposal on Anycast RP with PIM. The proposal attempts
   to provide anycast RP functio without using MSDP.
   Gist is to form a set of RPs configured with the same RP address
   (any cast address). Each DR sends registers to the closest RP,
   which will forward to the other RPs in the RP set. RPs accept
   these relayed PIM registers, but do not forward relayed PIM registers.
   Register-stop mesages between RPs are optional, reason is register
   stops happen between the DR and the first RP already. Two interoperable
   implementations from cisco and Procket have been done.

   A few comments were made about this proposal. One issue raised was
   packet losses resulted from loss of one PIM register (Mark H).
   Dino responded with such event is recovered upon the next register,
   and one lives with such occasional losses in the beginning. Another
   suggestion (Bill F?) was to do the relays via multicast forwarding.
   Dino's response was to forcus on the simplicity, and to avoid
   introduction of new machinary. Etc.

   Question to working group, does the working group want to take on
   this as a working group item ?

4. Jimei presented proposals on correctly matching a global address
   to a link-local IPv6 address for PIM rpf checks. Options include
   introducing a new PIM hello options that will list all addresses
   on a PIM neighor's interface; configuration based; etc.
   Also questioned if working group will take this as a working group
   item.

   Mark commented after a short discussion with a few spec coauthers
   that they are open to the idea of using a new PIM hello option,
   and to explicitly document this RPF address issue in the base spec.

5. Tom asked the working group for possible feedbacks on the PIM dense
   mode draft and the new PIM MIB draft. 2 people raised hands.
   Tom asked working group members to read and comment on the
   drafts, as usual.

I briefly conversed with Tom after the WG meeting that we
think we should continue the design discussions for 2 and 3 above
on the working group mailing list.

On the subject of the new PIM dense mode draft, Tom and I felt that
the best course of action is to move PIM dense mode draft to either
informational or experimental RFC, and get done with it. We will
request the new drafters to get the PIM dense mode draft into
a form suitable for submission. Still we need document reviews
from the working group members.

-Liming
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: jhingran <[email-masked]>
Date: Wed, 19 Mar 2003 16:10:34 +0100

Hi Liming,

  Can you pls explain me what is meant by
   "Each DR sends registers to the closest RP,
   which will forward to the other RPs in the RP set",
    as far as I understand, it doen't makes much sense to relay register
messages to "the other RPs in the RP set"?

Do you mean the following by the above statement:

Consider a network
                                                                    n-routers

---------------------//---------RP(a)----------------
R1
-SDR
|                                                                R2-SDR
 -------------------------------RP(b)---//-----------

n -routers

Here both the RPs share the same RP address (e.g.   the loopbacks  )
Now if RP(a) receives a register message from R2, then it needs to do is a
unicast route lookup and
relay the reg to the other anycast RP(b).

 If yes then this might be an overhead for pim as it needs to keep track of
the unicast topology.

regards,
Prashant

---

From: Liming Wei <[email-masked]>
Date: Wed, 19 Mar 2003 13:46:55 -0800 (PST)

Jhingran,

I am just the note taker:-).

But to respond to your observation, The unicast route lookup is
different from having to "keep track of unicast topology". Please keep
in mind that we are talking about an anycast RP mechanism, and we are
trying to replace MSDP with this mechaism. So a comparison with MSDP
would provide a better angle. 

-Liming
----------
> From: jhingran <[email-masked]>
> 
> Hi Liming,
>

---

From: John Zwiebel <[email-masked]>
Date: Wed, 19 Mar 2003 13:49:59 -0800

> 3. Dino presented proposal on Anycast RP with PIM.

>    packet losses resulted from loss of one PIM register (Mark H).

Bill Nickless was very much in favor of -not- encapsulating data in the
registers between anycast-RPs but only using NULL registers to alert
the other RPs in the group that they should join to the SPT.

Mark's point would then be exacerbated since it would guarantee that the
first packet would be lost.

I (jzwiebel) was unable to gain microphone access to ask the following
(Note that this is really a "whole different discussion").

   "How realistic is it to expect the network to be able to just 
'handle' all
    mpackets dumped on to the network and -not- expect loss?"

This is a question that has been hanging around since the beginning of
multicasting and it has consistently been ignored.  Many, if not most,
multicast apps used in the interdomain environment do not care whether
or not the first packets are lost.  Many applications in the intradomain
environment (although I can't say most) do not care about the first
series of packets.  Because of this we have not addressed any sort of
request-to-send/cleared-to-send procedure or a handshake procedure
between sources and receivers.

As we move from ASM to SSM and bi-dir, we are going to still be faced
with this same question.  How does one coordinate between the
source and all the receivers to establish some kind of a "start" 
message?

IMHO, if such a message does not exist, any debate concerning the loss
of the first, second, third or even 100th data packet (meaning 1 through
100) is useless.

One possible message would be similar to typing "AT" on your modem.
If such a message did exist, then 60 seconds (or more) worth of "AT" 
packets
could be sent out to coordinate the start of the interesting data.  This
crude example has its own problems in that now you delay delivery of
data for an extended period.

But the point is that unless we recognize that dropping the first data
packets is not always important, and that it is going to be nearly 
impossible
to fix as long as we have to depend on PIM registers and MSDP, we
are going to continue voicing our prejudices concerning these first
few packets and not working toward solving the problem.

(Although the problem could be identified as "you dropped the first
packet", there are many folks who are unwilling to view that as a
problem so lets move on.)

>    to a link-local IPv6 address for PIM rpf checks.

Someone suggested that this problem is not unique to PIM.  (Dino
had a rant about link-local addresses being a "bug" -- I agree with
him that they are a pain).  It may be that this problem should be
solved by one of the IPv6 working groups.

---

From: Mark Handley <[email-masked]>
Date: Wed, 19 Mar 2003 14:07:08 -0800

>between sources and receivers.

The multicast world seems to be shaping up as follows:

 - streaming applications (video broadcast, conferencing, file
   transfer) seem to be a good match with SSM.

 - discovery applications (svrloc, Apple Rendezvous, etc) are only
   served by ASM, but don't generally need really large scope.

In the light of this, the apps that are well suited to ASM and can't
be supported by SSM tend to be low rate bursty apps.  

For the streaming apps, there's probably not a big issue if a bunch of
packets in the first few hundred milliseconds get lost, but SSM isn't
likely to lose those packets anyway unless the receiver joins late.

For the discovery apps, it *really* matters if you don't get the first
few packets through.  

Thus the apps that really *need* ASM will be the ones that get hurt
most of if you drop the first few packets.  Of course if they start up
and immediately send at a high rate, all bets are off.

Cheers,		
	Mark

---

From: Liming Wei <[email-masked]>
Date: Wed, 19 Mar 2003 14:13:58 -0800 (PST)

Welcome back Z.

On the first issue, the key is to realize that this is a replacement
for MSDP. I think a sensible choice is to accept the fact majority
of these RP-relayed registers will be received, and for the minority
of packets lossed, the design allows a silent period util the next
periodic register occurs. I believe this is the same as the MSDP
behavior.

On the second issue about multiple addresses, I spoke with some one
working on OSPF (let me not mention the name here) afterwards. I do
think there is significant benefit in using a PIM option to convey all
addresses. Relying on a collection of other mechaisms (like neihgbor
discovery etc) does not appeal to me to be good design choices. I
think Mark and company made a good choice on using a new PIM option.

-Liming
------------
> From: John Zwiebel <[email-masked]>
>

---

From: Bill Nickless <[email-masked]>
Date: Wed, 19 Mar 2003 17:37:09 -0600

At 01:49 PM 3/19/2003 -0800, John Zwiebel wrote:

>   "How realistic is it to expect the network to be able to just 'handle' all

Remember that IP multicast, as defined in RFC-1112, was originally intended 
to give IP applications access to the broadcast-nature of a Metcalfe 
Ethernet.  RFC-1112 doesn't say anything other than there "may" be gateways 
to move IP multicast packets between Ethernets.

I think we've learned four lessons since 1989:

  <A> There is a class of application that wants one-to-many
      distribution of IP packets, even when the sources and
      receivers are on different Ethernet (and other) LANs.

  <B> What's appropriate on a Metcalfe Ethernet--transmit at will
      because everyone will hear you anyway--doesn't scale to an
      Internetwork.

  <C> IP Multicast deployments that use source-based distribution
      trees can and do scale to large Internetworks.

  <D> Source-rooted distribution trees should be maintained so
      long as either (1) there's traffic emitted by that source
      to interested receivers or (2) there is expressed receiver
      interest in receiving traffic from that source.

>    served by ASM, but don't generally need really large scope.

[...]

>and immediately send at a high rate, all bets are off.

I would characterize discovery apps slightly differently---

For the discovery apps, it *really* matters that packets get through, even 
if they're at a low frequency.

One problem with certain discovery apps is that they don't emit packets 
with a high enough frequency.  This violates Lesson <D> above.  The 
source-rooted distribution trees don't exist long enough to carry the 
packets from the low-frequency source to all the interested receivers.

Data encapsulation in PIM Register or MSDP SA messages violates Lesson <B>.

My position:

1. Deprecate data encapsulation in PIM Register, MSDP SA, and all
    other such spreading-knowledge-of-active-source messages.

2. Apply lessons <A> through <D> above to multicast applications.
    Specifically, require applications to either (i) use SSM or (ii)
    maintain a minimum frequency of sourced packets.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

---

From: "Purvi" <[email-masked]>
Date: Wed, 19 Mar 2003 15:46:29 -0800

I have not gone through Anycast proposal, so much of my doubt and the
solution here might seem beaten up by you all but I am wondering about
initial packet drop and also about register-stop messages between RPs
being optional. and would also like to know about the feasibility of the
behavior mentioned in point 2 of this email.

1) Is it that first RP just forwards the register packet received from DR?
    If it is then out of many similar cases consider a case where first RP
    receives register from DR and since it does not have any  state for G
    (*,g) or (*,*,rp), it sends register stop immediately.
    And relayed register message cannot reach other RPs . So
    all receivers which are interested have to wait for next 60 seconds.
And
   even after  that in next register cycle, same thing can be repeated.

   This looks like big loophole in the protocol. PIM SM atleast tried to
   reduce problem by  making DR send register message till it receives stop,
   BUT in this case the initial packet problem is outrightly ignored.
   (is this over simplification ?? or I have got something wrong in my
    understanding)

2) I have this question above because  I can think of more complicated but a
   little more robust behaviour where first RP waits for register stop from
all
   RPs or have some max time for which it waits for stop
   and times out before it stops sending register packet to other RPs.
    Ofcourse many variant of this solution are possible but tweaking the
behaviour.

   And this registering and register from DR can be completely decoupled and
   some optimizations like sending just null registers are always possible.
   With some latitude, I can compare this to heirarchical model. one source
   lets one RP know and that RP registers to other RPs till needed.

-Regards,
Purvi

---

From: John Meylor <[email-masked]>
Date: Thu, 20 Mar 2003 10:42:34 -0800

Bill Nickless wrote:
> 1. Deprecate data encapsulation in PIM Register, 

what would you do for SM deployments which leverage the shared
tree?

> MSDP SA, and all

registers in true shared-tree SM mode are moving more than
information about active sources, they are moving data to
the distribution tree.   There are signficant deployments
using this well described, long established model.

I agree SSM is a much simplier model for the network, 
- we need ubiquitous v3 support in apps/stacks/l2 devices,

and that it could even be the network service for dynamic 
multisource groups, 
- we some out-of-band dynamic source discovery element

nothing is stopping either of those except market pressure

but we won't get any closer to these SSM based models
by breaking currently working ASM models.

 john

---

From: Bill Nickless <[email-masked]>
Date: Thu, 20 Mar 2003 13:27:18 -0600

>what would you do for SM deployments which leverage the shared

Let them continue to exist and operate like they are.  The existence of PIM 
Register encapsulation in current deployments does not offend me.  :-)

>the distribution tree.   There are significant deployments

Moving data in the control plane is inherently a bad idea.  Granted, we've 
been doing it for many years, but it's still a bad idea.

>- we need ubiquitous v3 support in apps/stacks/l2 devices,

"Deploy IGMPv3" is not a sufficient transition strategy.

We're only setting ourselves up for failure by making IGMPv3 snooping the 
cornerstone of a transition to SSM.  IEEE 802.1 bridges should be left to 
operate on IEEE 802 frames.  IP Multicast, like other IP protocols, must be 
media agnostic and not place requirements on underlying transport.

At least three approaches have been described that could support IP 
Multicast operation on IEEE 802 compliant networks, without requiring the 
IEEE 802.1 devices to understand IGMP/IP or MLD/IP:

  - IEEE 802.1p GARP/GMRP provides a way for IP-speaking hosts to control
    how Ethernet multicast frame distribution is constrained.  (I've
    written about that approach at some length in
    draft-ietf-mboned-iesg-gap-analysis-01.txt .)

  - Radia Perlman and Keyur Patel have outlined a concept for
    using IP unicast encapsulation to traverse subnetworks that
    otherwise aren't configured for IP multicast forwarding.
    (See draft-keyur-pim-host-extensions-00.txt .)  Their draft
    defines receiver behavior, but could be easily extended to
    cover source extension.

  - Dave Thaler, Mohit Talwar, Lorenzo Vicisano, and Dirk Ooms
    have also described an automatic tunneling mechanism for SSM
    deployment.
    http://www.ietf.org/proceedings/01mar/I-D/mboned-auto-multicast-00.txt

>- we some out-of-band dynamic source discovery element

Agreed.  Google works for finding lots of sources, or at least finding 
application servers that can dynamically spread knowledge of active sources.

>nothing is stopping either of those except market pressure

One clear advantage of the Perlman/Patel approach is that it restructures 
market pressures:

  - It bypasses the energy barrier of IGMPv3 deployment at all edges.
    This allows applications to operate correctly, demonstrating demand.

  - When applications operate in the Perlman/Patel mode of unicast
    encapsulation, each individual stream consumes network bandwidth.
    This may motivate customer networks to deploy SSM closer to their
    networks, in order to optimize the use of their bandwidth towards
    the Internet core.

  - It allows core network operators to leverage their existing support
    for SSM-mode routing.

For this reason, I think a transition approach in the spirit of 
Perlman/Patel should be encouraged.

>by breaking currently working ASM models.

Again, I'm not advocating that we break existing deployments.  What I am 
advocating is:

  - Making a conscious decision to refine the model of what we are
    trying to support, so that what we support can be scalably deployed.

  - Defining transition mechanisms to enable SSM applications without
    requiring end-to-end IGMPv3 deployment.

===

---

From: Stig Venaas <[email-masked]>
Date: Thu, 20 Mar 2003 22:46:49 +0100

On Thu, Mar 20, 2003 at 01:23:13PM -0800, [email-masked] wrote:
> All intra-domain from what I've seen. Is this true John? Or are you aware
> of any deployments using ASM for anything OTHER THAN source discovery in
> the interdomain space?

Sure there is. Not that much used, but there are cases where say one
university streams something that someone in another university want
to see. And I guess one good example is the IETF multicast sessions (:
Some of us have also done videoconferences with mbone tools between
domains.

Stig

---

From: Bill Nickless <[email-masked]>
Date: Thu, 20 Mar 2003 15:53:08 -0600

>Some of us have also done videoconferences with mbone tools between

Streaming media applications work just fine when the network spreads the 
knowledge of active sources, to support interested receiver networks 
joining source-rooted distribution trees.

Streaming applications don't require the network to spread the initial 
packets of each stream in the control plane.

===

---

From: Stig Venaas <[email-masked]>
Date: Thu, 20 Mar 2003 22:59:17 +0100

> joining source-rooted distribution trees.

Agreed, I also dislike the control plane being used for data transport.

Stig

---

From: Bill Nickless <[email-masked]>
Date: Thu, 20 Mar 2003 16:05:33 -0600

At 01:56 PM 3/20/2003 -0800, [email-masked] wrote:

>Going back to John's concern about the current deployed base of ASM
>intra-domain networks.. Thinking about this somemore, I think here too we
>can separate network-based source discovery (NBSD) from shared-tree
>distribution.
>
>In these enterprise networks, I believe the applications currently use
>NBSD because they can. There really is nothing advantages about it. What
>the DO want and need is shared-tree distribution. In fact, in the most
>recent deployments, they engineer the network to ensure ALL sources stay
>on the shared tree - so they don't bother 'discovering' any sources: they
>just take them all down the shared-tree.

In the context of these deployments....

Can you characterize what the relative value accrues to having multiple 
sources sharing a distribution tree?

More specifically: are there enough unique sources to preclude static 
configuration of multiple source-rooted distribution trees?

What is the "tipping point" between when a shared tree should be used 
versus multiple source-rooted trees?

>So am I far enough off topic yet? ;-)
>
>Greg

That's never stopped me before!  :-P

===

---

From: Stig Venaas <[email-masked]>
Date: Thu, 20 Mar 2003 23:07:26 +0100

On Thu, Mar 20, 2003 at 01:56:10PM -0800, [email-masked] wrote:
> On Thu, 20 Mar 2003, Stig Venaas wrote:
> This IS a PRIME example of using ASM for network-based source discovery
> ONLY. There are no inter-domain shared trees.

Oh okay, I see what you're asking for now. Ignore my mail please.

Stig

---

From: John Zwiebel <[email-masked]>
Date: Thu, 20 Mar 2003 14:27:48 -0800

On Thursday, March 20, 2003, at 02:09 PM, <[email-masked]> wrote:

>
> S,G state explosion for many-to-many applications is the trigger.

There is also the question of the diameter of the multicast group.
IMHO, interdomain multicast is not going to ever get to the size
that a shared-tree will be useful.  But since one should never
say never (again), the need for share-trees in the interdomain
space is not going to happen for years.

In the enterprise space the need is already here.

I believe the applications requiring the shared-trees are more
"deterministic" in that the location of the sources and receivers
is well known and under fairly strict control, which limits the
need for shared-trees to the enterprise.

Interdomain traffic is much more ad hoc in that there is little
control over the location of the sources and receivers.  At the
same time, little need for coordination between sources (which
may exist in the enterprise space.)

but we are drifting quite afar from the need to figure out how to
coordinate between sources and receivers on when the data stream
will begin.

>
> Greg
>
> On Thu, 20 Mar 2003, Bill Nickless wrote:
>

---

From: <[email-masked]>
Date: Thu, 20 Mar 2003 14:09:02 -0800 (PST)

Greg

---

From: <[email-masked]>
Date: Thu, 20 Mar 2003 13:23:13 -0800 (PST)

I think we need to disassociate ASM as it applies to
shared-tree distribution from network source-discovery. The intra-domain
deployments use both, but interdomain only uses the source-discovery
element of ASM. True? 
 
> - we some out-of-band dynamic source discovery element

There is nothing special about doing source-discovery in the network that
can't be accomplished at the application layer.

> by breaking currently working ASM models.

Agreed. 

BUT, it was evident too me this week that over 90% of the efforts in the
mcast wg's I attended, was spent dealing with network-based source
discovery. The law of diminishing returns must apply sometime.

Greg

---

From: <[email-masked]>
Date: Thu, 20 Mar 2003 13:56:10 -0800 (PST)

Greg

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 22 Mar 2003 21:29:15 +0900

>>>>> On Wed, 19 Mar 2003 13:49:59 -0800, 
>>>>> John Zwiebel <[email-masked]> said:

> Someone suggested that this problem is not unique to PIM.

Correct (as I admitted at the presentation), but at the same time,
"protocol independence", a unique characteristic of PIM, is one the
major sources of the issue.

> (Dino
> him that they are a pain).

I admit link-local addresses introduce a pain, but it also provides
benefits.  In fact, the IETF is introducing link-local addresses even
in the IPv4 world by the zeroconf wg.  There may still be people who
just think the notion of link-local is a bug and should be killed, but
the fact shows it is at least controversial whether we should have
link-local or not.  So, I'd be glad if we could concentrate on the
issue based on the fact we have link-local addresses, rather than
discuss the validity of having link-local here.

> It may be that this problem should be

I don't mind to discuss this somewhere else if it is more appropriate
place than here.  However, as some other people have pointed out in
this list, the issued addressed in the draft is not necessarily
specific to IPv6 (we the authors realized this point, but mainly
focused on the IPv6 issue in the draft since this is the most
practical one we've seen).

I still believe the pim wg is the best place, and would really
appreciate if the wg allows us to discuss the issue here.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 22 Mar 2003 21:38:05 +0900

>>>>> On Wed, 19 Mar 2003 14:13:58 -0800 (PST), 
>>>>> Liming Wei <[email-masked]> said:

> think Mark and company made a good choice on using a new PIM option.

Thanks, (as I said at the presentation) though we do not stick to a
particular solution, especially the new hello option, at this moment,
there seems to be some interest in pursuing the idea.

So, what should we do on this?  We're willing to either

- to revise our draft with more details of the hello option, or
- to contribute some text on this issue and the option to the main PIM
  specification
(or whatever else we can)

Would you chairs suggest a proper course of action, please?

Thanks,

					JINMEI, Tatuya

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 22 Mar 2003 09:03:01 -0800

>> discuss the validity of having link-local here.

    Can you explain what the real benefits are of link-local addresses.

Dino

---

From: Liming Wei <[email-masked]>
Date: Sat, 22 Mar 2003 13:27:57 -0800 (PST)

Jinmei,

Here is what I think:

1) There exists multple addresses on an interface in IPv6;
2) We need to specify how PIM works under such scenarios.

Else, it will be a mess in the field when it comes to
interoperability. In short, a solution on 2) should be discussed
in the PIM WG.

About the disadvantages (or benefits) of multiple addresses in IPv6,
it is interesting (boring after a couple of messages in thread) to be
informed of the activities elsewhere, but lengthy discussions here
will not change the outcome in IPv6's design, or zeroconf's design.

Can you coordinate with Mark et al on this issue ?

 Thanks,
-Liming

P.s. Somehow all your emails ended up in my spam folder (which I clean
up once every 2 weeks). I guess it is due to the following in your
email header:

Received: from localhost (unknown [3ffe:501:4819:2000:95e4:ac11:b66a:f62f])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id 7F65615210; Sat, 22 Mar 2003 21:38:01 +0900 (JST)

Mail-from: From [email-masked]  Sat Mar 22 04:38:13 2003
Date: Sat, 22 Mar 2003 21:38:05 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pim] San Francisco PIM WG meeting minutes
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
Lines: 29

Thanks,

					JINMEI, Tatuya

---

From: Bill Nickless <[email-masked]>
Date: Sat, 22 Mar 2003 20:19:39 -0600

At 01:27 PM 3/22/2003 -0800, Liming Wei wrote:

>1) There exists multiple addresses on an interface in IPv6;

There are plenty of situations where interfaces are associated with 
multiple IPv4 addresses as well.  Some PIM implementations don't take this 
into account.  In my experience, this has led to operational deployment 
confusion and difficulty.

One specific example involves HSRP/VRRP.  Unicast reachability is satisfied 
because the "active" HSRP/VRRP speaker responds to IPv4 ARP for the virtual 
address.  However, multicast reachability is broken because the "active" 
HSRP/VRRP speaker fails to respond to IPv4 PIM Joins addressed to the 
virtual address.

The result is a situation where unicast routing works just fine, but 
multicast routing is broken.  Such incidents contribute to the perception 
that multicast routing is more fragile or somehow less reliable than 
unicast routing.

===

---

From: Liming Wei <[email-masked]>
Date: Mon, 24 Mar 2003 12:13:18 -0800 (PST)

Bill,

I actually am thinking about cases invlving multiple addresses in
IPv4 envnronment too :-).

The HSRP or VRRP case sounds unusual. Why does a PIM joiner/pruner
have to rely on a "static default route" type of unicast routing ?

An implementation today can "solve" this problem by special-knob'ing
PIM to run from the VRRP active router only, and only "on" the virtual
address in PIM messages (as opposed to the physical addresses). Of
course, this is not as general/simple (robust?) as learning all
addresses via a PIM hello option.

-Liming
--------
> From: Bill Nickless <[email-masked]>
>

---

From: Nidhi Bhaskar <[email-masked]>
Date: Mon, 24 Mar 2003 12:23:56 -0800 (PST)

Hi,

I think we should discuss this in the PIM WG as well. And I vote for
going with the PIM hello option proposal. But I am not opposed to a
moving to a generic solution, when it becomes available.

AFAIK, Inverse ND (the generic solution suggested for ipv6) is not
widely implemented -- we need some way to fix this in the meantime.
Another issue is that Inverse ND works only on links that have link
layer addresses. I'm not sure if that will be a limitation for PIM,
but would be nice not to have this dependency. Also it looks like the
problem might exist in ipv4 and we don't have a generic solution for
that.

Perhaps we can continue to use an option number from the >6500 space
and deprecate it once generic solutions are available.

I'd also like to point out that this problem is not really due to ipv6
link-local addresses, but multiple addresses. We'd still have to solve
this if global ipv6 addresses were used in hellos. I.e there is a
problem as long as there is more than one address on the i/f.

And finally, suggest renaming to something like 'multiple address
advertisement' or 'address advertisement' option. Seems more apt than
'upstream detection'... to me atleast :)

Thanks,
Nidhi

---

From: Rahul Bahadur <[email-masked]>
Date: 24 Mar 2003 13:26:35 -0800

Liming, Bill,

Maybe I can chime in here. The VRRP/HSRP situation is not that unusual -
several vendors want to use the same pair of routers to back-up both
unicast and multicast traffic. However, they do want this pair to run
any unicast protocols but do want to use PIM for multicast failover.
Since the routers neighboring the VRRP pair only have a default route
pointing to the virtual address (which never matches that of a PIM
neighbor) both sparse-mode and dense-mode break at different times. Only
problem here is that users are expecting certain behaviour from one
protocol based on their experience with another. Liming, your solution
noted below is the obvious workaround.

Rahul

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2003 13:58:41 -0800

>> problem might exist in ipv4 and we don't have a generic solution for

    I think an even shorter-term solution is to send multiple Hellos with
    different source addresses. Then any router can do the right thing.

Dino

---

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 24 Mar 2003 14:38:19 -0800

>     different source addresses. Then any router can do the right thing.

This may not work for things like Prune overriding.
E.g., lets say that the upstream router addresses are A1 and
A2. If the downstream router sends a Join(*,G) with the upstream
router address set to A2, then when the upstream router has to send
PruneEcho on that interface, it may have to remember to put A2 as
the upstream router address rather than A1. Well, if another router
on that LAN uses A1 as the upstream router address for same G, then
that other router won't override the Prune or the PruneEcho. The
result: the interface with address A1 and A2 is pruned when it
should be in Joined state.

Indeed, I don't exclude the possibility that if someone does very
detailed analyses it may be found that the Prune overriding won't be
broken for some other reasons like Asserts or whatever, but the
point I want to emphasize is that the multiple Hellos makes the
protocol more fragile.
For example, one thing that will happen is that the number of the
neighbors will be miscalculated, and then when (*,G) Prune is
received, the PrunePending timer may be set to
J/P_OverrideInterval(I) instead of zero, because this behavior
depends on the number of neighbors.

(Here I should be "fair" to admit that approx a month ago when I
read draft-suz-pim-upstream-detection-00.txt, my first reaction was
that the multiple Hellos scheme may be a reasonable work-around that
wasn't mentioned in the draft, but now I see I was wrong :)

My preference is for the new Hello option rather than any
workarounds, because the new Hello option makes things clean and
explicit.

Pavlin

---

From: Nidhi Bhaskar <[email-masked]>
Date: Mon, 24 Mar 2003 14:46:58 -0800 (PST)

My only issue with this is the duration for which it might be
required... Given that it can have some side effects like turning off
PIM optimizations otherwise possible on 1 nbr links, increase nbr
processing, interfere with per nbr j/p pacing etc. Maybe others I
can't think of... These are probably only significant if we end up
using it for a long time.

Another issue -- it'll probably violate various ipv6 rfcs (+ the new
PIM draft) by using routable addreses in PIM messages :)

The hello option is almost as simple & avoids the above. It seems
cleaner without much overhead, so I have a preference for it.

Thanks,
Nidhi.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2003 14:57:05 -0800

>> should be in Joined state.

    This all depends if you treat the LAN as multiple logical subnets and
    running the protocol on each subnet. Most implementations don't so this
    because they don't want the unicast and multicast protocol overhead. If
    they need to do it for some reason, they then configure VLANs. 

    This really isn't a big problem with IPv4 since there is one instance
    of a unicast routing protocol running and each router is configured with
    a primary address on the same subnet.

    As long as the PIM hello protocol and the unicast routing protocol use
    the same set of addresses (same subnet or link-local versus same-subnet) 
    there shouldn't be a problem.

    So, let's back off. What real problem are we trying to solve?

>> wasn't mentioned in the draft, but now I see I was wrong :)

    It is reasonable if, say you were running OSPF on both subnets on the
    same wire. Then you could have upstream routes using next-hops on the
    different subnets.

>> workarounds, because the new Hello option makes things clean and

    My preference is to keep it the way it is. And if you have to do this,
    use VLANs. And for the IPv6 case, decide on a per LAN basis if all
    protocols will use link-local addresses for route table entries or 
    configured addresses for route table entries.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2003 15:16:11 -0800

>> PIM optimizations otherwise possible on 1 nbr links, increase nbr

    Agree. But not sure why JP pacing is affected by this since it is a per
    neighbor issue.

>> PIM draft) by using routable addreses in PIM messages :)

    Aren't we trying to improve the Internet with IPv6? I feel we are going
    in the opposite direction.

>> cleaner without much overhead, so I have a preference for it.

    Right.    

Dino

---

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 24 Mar 2003 15:24:51 -0800

>     a primary address on the same subnet.

If you relay on this, you are making an assumption about the
behavior of the underlying unicast routing protocol, so PIM is not
protocol-independent anymore :)
Not to mention that if someone decides to use static IP routing with
IP aliases on an interface, then running PIM-SM on top of it will
add additional constrains on how the routing is configured.

>     So, let's back off. What real problem are we trying to solve?

For me, it is making sure that PIM-SM works in an environment where
there is more one IP address per interface, but without making
specific assumptions about how the underlying unicast routing
works.

>     configured addresses for route table entries.

Yet another thing that can go wrong.
If it is kept the way it is, then you have always to explain this
issue to your customers, which is just more headaches for them (and
for your customer support :).

Regards,
Pavlin

---

From: "Purvi" <[email-masked]>
Date: Mon, 24 Mar 2003 15:53:23 -0800

And its not just sending hello pkts on all interfaces of same subnet or
using
all ip addresses of the interface to facilitate joins but it also involves
sending
prune echos using all ip addresses on that subnet/interface and even
transmitting BSR messages using all ip addresses. And ipv4 n/ws do have this
problem.
Hello option does seem better to all these useless duplicates.

Purvi

----- Original Message -----
From: "Pavlin Radoslavov" <[email-masked]>
To: "Dino Farinacci" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, March 24, 2003 3:24 PM
Subject: Re: [pim] San Francisco PIM WG meeting minutes

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2003 16:29:05 -0800

>> add additional constrains on how the routing is configured.

    Pavlin, this is simply PIM looking in the unicast routing table for a
    next-hop to a source or RP. If you make Hellos consistent with the
    routing table next-hop, there isn't a problem. 

>> specific assumptions about how the underlying unicast routing

    PIM in and of itself is not making any assumptions. You just interpreted
    it that way.

>> for your customer support :).

    PIM over VLANs are in wide-spread use today. I consider it a done-deal.

Dino

---

From: Nidhi Bhaskar <[email-masked]>
Date: Mon, 24 Mar 2003 16:24:54 -0800 (PST)

>     Agree. But not sure why JP pacing is affected by this since it is a per

I was thinking if you wanted to send j/ps at a certain rate to each
nbr, having say 3 nbrs that map to one physical box would mean you'd
send at 3 times what you intended to. But I think others have
pointed out other more basic problems...

>     in the opposite direction.

Well, deprecating site-locals was one step in the "right" :) direction
this ietf. Perhaps we'll see more as ipv6 gets wider deployment.

Nidhi.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 24 Mar 2003 13:02:25 -0800

In message <[email-masked]> you write
>moving to a generic solution, when it becomes available.

This seems like the best solution to me as well.
When I said that I thought we had solved the problem internally,
it turns out we just required static nexthops to have link local
addresses which doesn't really solve the problem in all cases.

>problem as long as there is more than one address on the i/f.

I think its entirely due to IPv6 link-local addresses.

In v4, you can have multiple addresses but you can only have a single
address on a subnet. This allows you to consistenly have the same
neighbor address as upstream router address.

With v6, this isn't true because you have a link local address and
possibly also one or more global addresses. So your neighbor will always be
the link local but your upstream router address may be any of them.

Thanks,
Tom

---

From: Brian Haberman <[email-masked]>
Date: Mon, 24 Mar 2003 16:08:15 -0500

Nidhi,
      After thinking about the multiple address issue in v4,
I agree with your suggestion and think we should look at a
PIM option to deal with the problem.

Regards,
Brian

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2003 21:00:08 -0800

>> pointed out other more basic problems...

    Only if they were RPF neighbor for your multicast routes.

>> this ietf. Perhaps we'll see more as ipv6 gets wider deployment.

    Anyone for deprecating link-locals?  ;-)

Dino

---

From: SUZUKI Shinsuke <[email-masked]>
Date: Tue, 25 Mar 2003 16:23:17 +0900

Hello all,

>>>>> On Sat, 22 Mar 2003 09:03:01 -0800
>>>>> [email-masked](Dino Farinacci)  said:

>     Can you explain what the real benefits are of link-local addresses.

I feel the "link-local" keyword might be one of the reason of the
long thread.
(Although the problem to be resolve in this draft is caused by the
 multiple address assignment on one link, not specific to link-local
 address)

Actually we intentionally used the word "link-local" based on the
following expression in draft-ietf-pim-sm-v2-new-07.txt.

> 4.10.  PIM Packet Formats
> (snip)
> PIM messages are either unicast (e.g.  Registers and RegisterStop), or
> multicast with TTL 1 to the `ALL-PIM-ROUTERS' group (e.g. Join/Prune,
> Asserts, etc.).  The source address used for unicast messages is a
> domain-wide reachable address; the source address used for multicast
> messages is the link-local address of the interface on which the message
                  ~~~~~~~~~
> is being sent.

In case of IPv6, it's explicitly defined in RFC2373, but AFAIK there's
no explicit definition in IPv4.  So can anyone clarify this definition?

If I misunderstand the intention of "link-local" this draft, I'd like
to change the wording in our draft based on that.

Thanks,
----
SUZUKI, Shinsuke @ Hitachi / KAME Project
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Mar 2003 23:53:02 -0800

>> (Although the problem to be resolve in this draft is caused by the

    I'm using the definition according to RFC 2373, which is specific to IPv6
    only.

>> no explicit definition in IPv4.  So can anyone clarify this definition?

    All IPv4 non-multicast addresses are routable addresses with some very few
    exceptions (i.e. 127.0.0.1, 255.255.255.255, directed broadcast, etc).

Dino

---

From: Bill Nickless <[email-masked]>
Date: Tue, 25 Mar 2003 13:44:10 -0600

At 12:13 PM 3/24/2003 -0800, Liming Wei wrote:
>Bill,
>
>I actually am thinking about cases involving multiple addresses in
>IPv4 environment too :-).
>

I've run across a half dozen different situations where departments of an 
institution hate each other, but one still has to depend on the other for 
Internet routing.  Typically, this is a computer science department and a 
computing center.

So they define a DMZ LAN where both sides have routers and both sides 
install static routes toward the other.  Because a dynamic routing protocol 
would require too much trust, one or both sides will configure HSRP/VRRP to 
provide redundancy.

This approach works fine with unicast routing because of how ARP/ND work.

It breaks some existing PIM implementations.

>addresses via a PIM hello option.

Consider this simple rule:

If a PIM speaker will respond to ARP/ND for a given address, then the PIM 
speaker should process PIM joins/prunes for that address.

This would cover link-local addresses, HSRP/VRRP, and secondary addresses.

Of course, proxy-ARP would be an exception to this rule.

===

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 26 Mar 2003 18:30:25 +0900

>>>>> On Mon, 24 Mar 2003 14:38:19 -0800, 
>>>>> Pavlin Radoslavov <[email-masked]> said:

> should be in Joined state.

Yes, this can happen.

A similar scenario can also happen for assert messages.  If an assert
message is sent from an address of an upstream router which is
different from the upstream address for a downstream router, the
downstream router will not switch the upstream router to the assert
winner.  In order to avoid this, the upstream router would have to
send assert messages using multiple source addresses, just like it
does so for hello messages.

In general, the trade-off between the multiple-source vs hello option
is:

- the multiple-source approach may have a less impact on the PIM
  specification (and implementations), than the hello option.
- the multiple-source approach will require more messages on the wire
  than the hello option approach.
- the multiple-source approach does not provide mapping among multiple
  upstream addresses.  Thus, we need a special handling whenever we
  need such mapping.  The prune-echo and assert cases are examples.

> wasn't mentioned in the draft, but now I see I was wrong :)

I noticed your message, but had not found time to make a response
before the presentation (sorry about that).  I added the yet-another
solution in the presentation slides, but I could not explain it due to
the time limitation.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 26 Mar 2003 18:33:10 +0900

>>>>> On Sat, 22 Mar 2003 13:27:57 -0800 (PST), 

(snip)

> Can you coordinate with Mark et al on this issue ?

Sure, then shall we privately contact Mark for the next step, or
continue the discussion here in the ML for a while?

> will not change the outcome in IPv6's design, or zeroconf's design.

I agree, and sorry for my lengthy comments on this.  I'll refrain from
mentioning the off-topic in this list.

					JINMEI, Tatuya