Protocol Independent Multicast (pim)

Prashant Jhingran | 9 May 2007 08:14

RE: pim-sm router transitions from DR to non-DR

Hi All,

Had it been PIM-DM instead of SM, then of course Assert would have decided the forwarder on the LAN. But in case of PIM-SM, the RFC 4601 implicitly specifies how to handle such a scenario.

Section 4.5.6. & 4.5.7 i.e. Sending (*,G) & (S,G) Join/Prune Messages respectively specifies the following:

When JoinDesired (*,G) or (S,G) => False

Transition [J] state => [NJ] state ; Send respective Prune message viz. (*,G) or (S,G); Cancel respective Join Timer

Note: JoinDesired(*,G), depends on pim_include(*,G) which in turn depends on "I_am_DR( I )" bool.

Conclusion:

- On loosing DR Election, RT1 should send Prune mesg towards upstream & should remove the entry as well.

- RT2 (new DR) should form the tree by triggering Join mesg upstream towards RP..

- Thus Assert mesg need not decide the forwarder on the LAN.

Regards,
Prashant Jhingran

Huawei Technologies
+91-80-41117676 Ext -5129
Mobile:+91-9448927814
============================================
"Sing, dance, serve, meditate and celebrate"
- Sri Sri Ravi Shankar www.artofliving.org
============================================

From: Rajesh Nataraja [mailto:rbnataraja <at> gmail.com]
Sent: Friday, April 27, 2007 12:40 AM
To: Satyanarayana Dillikar
Cc: pim <at> ietf.org; Binu TN
Subject: Re: [pim] pim-sm router transitions from DR to non-DR

Hello,

I think the better way to do is to not care about being a DR or not, and just handle it based on what would happen if someone asserts, are there compatability issues here? What do authors say?

Thanks

Rajesh.

On 4/22/07, Satyanarayana Dillikar <dsatyana <at> broadcom.com> wrote:

Hi Binu,

See inline

From: Binu TN [mailto: tnbinu <at> yahoo.co.in]
Sent: Saturday, April 21, 2007 9:38 PM
To: pim <at> ietf.org
Subject: [pim] pim-sm router transitions from DR to non-DR

Hi,

I have a basic doubt in the pim-sm router transition from DR to non-DR. Let's assume a scenario where a sm router (e.g., RT1) is DR in a LAN and it has multicast route entry and it is trigerring Join messages to RP (it is in some other network) as it has some interesting hosts. If another sm router ( e.g.RT2) with higher IP address comes into the LAN of RT1, as per my understanding RT2 will become DR and RT1 will become non-DR to that LAN. My doubts are,

1) whether the multicast route entries that are present in RT1 before entry of RT2 will be removed?

[dsatya] Not necessarily, those entries will changed based on the unicast route change to RP. (due to insertion of RT2)

2) Will RT1 stops trigerring Join messages to RP? Or RT1 will be trigerring Join messages for existing entries and RT2 will be trigerring for any new entries?

[dsatya] RT1 should not trigger Join Msgs to RP and RT2 should take up the job.

Thanks

Satya

Please clear my doubts.
Thank you in advance.

Regards,
Binu.

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.

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

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

headers

John Zwiebel | 9 May 2007 19:23

Re: pim-sm router transitions from DR to non-DR

On May 8, 2007, at 11:14 PM, Prashant Jhingran wrote:

Had it been PIM-DM instead of SM, then of course Assert would have decided the forwarder on the LAN. But in case of PIM-SM, the RFC 4601 implicitly specifies how to handle such a scenario.

Section 4.5.6. & 4.5.7 i.e. Sending (*,G) & (S,G) Join/Prune Messages respectively specifies the following:

When JoinDesired (*,G) or (S,G) => False

Transition [J] state => [NJ] state ; Send respective Prune message viz. (*,G) or (S,G); Cancel respective Join Timer

Note: JoinDesired(*,G), depends on pim_include(*,G) which in turn depends on "I_am_DR( I )" bool.

Conclusion:

- On loosing DR Election, RT1 should send Prune mesg towards upstream & should remove the entry as well.

- RT2 (new DR) should form the tree by triggering Join mesg upstream towards RP..

- Thus Assert mesg need not decide the forwarder on the LAN.

Guaranteeing that the receiver on this LAN will miss packets.

IMHO, it is up to the implementation to determine whether it wants to

rely on an assert or the RFC specified process.

A couple of toplogies that you might find interesting.

RT1 RT1 RT2

| | |

----+------+--- --+-+----+----+

| | | |

RT2 H H RT3

topo 1 topo 2

What happens in topo1 when RT2 becomes the DR? Do you really want

RT1 to send prunes upstream only to have RT2 reset the same path?

And in topo 2, when RT1 is the DR, but loses to RT3 and RT3 picks RT2 as the

RPF router, now what happens?

Which then brings up my "favorite" conundrum, which has nothing to do

with this thread (well, perhaps in an peripheral way...) Make RT3 the DR

and have it switch RPF from RT1 to RT2 (with or without H), the RFC says

send a join to RT2 and prune to RT1. On a multiaccess LAN this just

generates a lot of excess control traffic and, depending on the data rate,

probably won't avoid an assert anyway. And if you have many downstream routers

the problem becomes even worse.

Of course an implementation has to consider whether it can deal well with

asserts, which are inherently evil.

And we are talking about a "corner case" since multiaccess-LANS are becoming

more and more rare. Which then brings up the question on a P2P network, if a

router does an RPF change, is it more advantageous to Prune off the old link or

to just let it timeout.

R1 R2

\ /

R3

R1 is the RPF, it changes to R2, Pruning the R1-R3 link immediately gets you exactly what?

Consider what happens if it is a unicast routing flap. Do you really want prunes sent up the R1

branch only to be followed immediately by joins when unicast "flaps back"?

Those messages are potentially sent all the way to the root of the tree.

I'm not offering any answers on the way it "should be done".

Oh, and we haven't addresses the fact that there may be an L2 switch in between which may or

may not participate in the forwarding decision.

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

headers

Su Haiyang | 10 May 2007 05:17

RE: pim-sm router transitions from DR to non-DR

Dear All,

I think more reliability of PIM-SM protocol should be considered at the next draft.

Considering that MPLS’s LSP has the concept of “Make before break”, why the PIM WG

leaves this issue as an implementation-specific one?

Just like the topologies both of you have mentioned in your email, at least when the DR switches and RPF changes,

PIM should consider the mechanism of preventing data from losing.

Su Haiyang

From: John Zwiebel [mailto:jzwiebel <at> cisco.com]
Sent: Thursday, May 10, 2007 1:24 AM
To: prashantj <at> huawei.com
Cc: pim <at> ietf.org; 'Satyanarayana Dillikar'; 'Binu TN'
Subject: Re: [pim] pim-sm router transitions from DR to non-DR

On May 8, 2007, at 11:14 PM, Prashant Jhingran wrote:

Had it been PIM-DM instead of SM, then of course Assert would have decided the forwarder on the LAN. But in case of PIM-SM, the RFC 4601 implicitly specifies how to handle such a scenario.

Section 4.5.6. & 4.5.7 i.e. Sending (*,G) & (S,G) Join/Prune Messages respectively specifies the following:

When JoinDesired (*,G) or (S,G) => False

Transition [J] state => [NJ] state ; Send respective Prune message viz. (*,G) or (S,G); Cancel respective Join Timer

Note: JoinDesired(*,G), depends on pim_include(*,G) which in turn depends on "I_am_DR( I )" bool.

Conclusion:

- On loosing DR Election, RT1 should send Prune mesg towards upstream & should remove the entry as well.

- RT2 (new DR) should form the tree by triggering Join mesg upstream towards RP..

- Thus Assert mesg need not decide the forwarder on the LAN.

Guaranteeing that the receiver on this LAN will miss packets.

IMHO, it is up to the implementation to determine whether it wants to

rely on an assert or the RFC specified process.

A couple of toplogies that you might find interesting.

RT1 RT1 RT2

| | |

----+------+--- --+-+----+----+

| | | |

RT2 H H RT3

topo 1 topo 2

What happens in topo1 when RT2 becomes the DR? Do you really want

RT1 to send prunes upstream only to have RT2 reset the same path?

And in topo 2, when RT1 is the DR, but loses to RT3 and RT3 picks RT2 as the

RPF router, now what happens?

Which then brings up my "favorite" conundrum, which has nothing to do

with this thread (well, perhaps in an peripheral way...) Make RT3 the DR

and have it switch RPF from RT1 to RT2 (with or without H), the RFC says

send a join to RT2 and prune to RT1. On a multiaccess LAN this just

generates a lot of excess control traffic and, depending on the data rate,

probably won't avoid an assert anyway. And if you have many downstream routers

the problem becomes even worse.

Of course an implementation has to consider whether it can deal well with

asserts, which are inherently evil.

And we are talking about a "corner case" since multiaccess-LANS are becoming

more and more rare. Which then brings up the question on a P2P network, if a

router does an RPF change, is it more advantageous to Prune off the old link or

to just let it timeout.

R1 R2

\ /

R3

R1 is the RPF, it changes to R2, Pruning the R1-R3 link immediately gets you exactly what?

Consider what happens if it is a unicast routing flap. Do you really want prunes sent up the R1

branch only to be followed immediately by joins when unicast "flaps back"?

Those messages are potentially sent all the way to the root of the tree.

I'm not offering any answers on the way it "should be done".

Oh, and we haven't addresses the fact that there may be an L2 switch in between which may or

may not participate in the forwarding decision.

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

headers

John Zwiebel | 10 May 2007 18:24

Re: pim-sm router transitions from DR to non-DR

Please feel free to propose a totally protocol, or whatever protocol changes you think

are in order, that takes advantage of the last 15 years of multicast protocol development

and deployment. I'm sure you'll not have any trouble gaining consensus and that

your plan will integrate seamlessly into legacy deployments.

On May 9, 2007, at 8:17 PM, Su Haiyang wrote:

Dear All,

   I think more reliability of PIM-SM protocol should be considered at the next draft.

   Considering that MPLS’s LSP has the concept of “Make before break”, why the PIM WG

leaves this issue as an implementation-specific one?

   Just like the topologies both of you have mentioned in your email, at least when the DR switches and RPF changes,

PIM should consider the mechanism of preventing data from losing.

Su Haiyang

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

headers

Mark Doll | 14 May 2007 22:30

Bootstrap Router Mechanism: Forwarding of non-preferred BSMs

Hi!

I have questions/comments regarding the forwarding of non-preferred BSMs in
the Bootstrap Router Mechanism, as specified in draft-ietf-pim-sm-bsr-10.txt.

First:
=====
Why do routers in state "Candidate BSR" forward non-preferred BSMs from the
elected BSR (and switch to state P-BSR), but routers in state "Accept
preferred" don't?

As es result, a C-BSR will see BSMs with a lowered priority from the elected
BSR only if directly adjacent to it.

I don't get the point, why to distinguish this special "adjacent C-BSRs" case
instead of simply ignoring a lowered priority from the elected BSR, time out,
let the routers in the domain switch to state "Pending BSR" and "Accept Any",
respectively, and restart the election as it happens in the case of
non-adjacent C-BSRs. So why not just specifying for routers

When in C-BSR state:
Event: Receive Non-preferred BSM
Action: -> C-BSR state

(was:
Event: Receive Non-preferred BSM from Elected BSR
Action: -> P-BSR state; Forward BSM; Set Bootstrap Timer to BS_Rand_Override
)

Second:
======
Why forwarding non-preferred BSMs when in state "Pending BSR"?
Shortly afterwards, the router itself will send a BSM with a higher priority,
so forwarding is useless anyway. So why not specifying for routers

When in P-BSR state:
Event: Receive Non-preferred BSM
Action: -> P-BSR state

(was:
Event: Receive Non-preferred BSM
Action: -> P-BSR state; Forward BSM
)

Third:
=====
As an alternative to first and second above, always forward a non-preferred
BSMs if they come from the elected BSM router, to quickly restart the BSR
election:

When in Accept Preferred state:
Event: Receive Non-preferred BSM from elected BSR
Action: -> AP state; Forward BSM; Store RP-Set; Set Bootstrap Timer to
BS_Timeout; Set SZT to SZ_Timeout

(was:
Event: Receive Non-preferred BSM
Action: -> AP state
)

and

When in P-BSR state:
Event: Receive Non-preferred BSM from elected BSR or if elected BSR is unknown
Action: -> P-BSR state; Forward BSM

(was:
Event: Receive Non-preferred BSM
Action: -> P-BSR state; Forward BSM
)

I would prefer third.

Regards, Mark Doll.

P.S.: BTW, just a nit: In the current draft, it's not explicitly specified,
that routers in state "Candidate BSR" do not forward non-preferred BSMs from
other BSRs than the elected BSR. Yes, it's a no-op, so it can be savely
omitted, but then the other no-op "When in Accept Preferred state, Event:
Receive Non-preferred BSM, Action: -> AP state", should be omitted, too.

headers

Benoît HILT | 15 May 2007 17:09

New Internet draft

Hello,

a new internet-draft is available in the IETF repository (http://www.ietf.org/internet-drafts/draft-hilt-pim-tree-unreachability-00.txt).

Title : Join failure notification for PIM-SM multicast routing

Abstract

"Currently, PIM-SM is the most widely deployed multicast routing protocol in the Internet. Nevertheless this multicast protocol lacks a simple connectivity debugging function, making it difficult to identify for example; -multicast routing problem, -source unavailability, -RP failure, etc... When a host wants to receive a multicast group/channel, if for any reason the associated tree branch cannot be built or breaks down, nothing exists to inform the receiver or its network about this failure.

We propose here a new PIM message suitable for Join forwarding error notification. It is able to inform where and why such an error happened in the network and this without using a multicast traceroute mechanism. This message can then be used to reduce globally the impact of useless branches in a PIM domain.

Furthermore it could be used to block DDoS (Distributed Denial of Service) attacks.

After the presentation of a first version of this work at the 66th IETF meeting we have taken into account comments and suggestions and we would like to present this revised work in the PIM WG at the 69th IETF/Chicago meeting.

Before thas, we would like to get comments and engage discussion with the PIM and MBoned working groups in their mailing lists.

Differences between earlier version are;

- the message is now called Tree Unreachability instead of Group Unreachability

to reflect more precisely its purpose,

- the message is now presented as a new PIM/SM message,

- in the current draft we make some attempts about how this new message could be used in a fully managed multicast domain.

Benoît HILT

Benoît HILT - Dépt. R&T

IUT de Colmar - BP 50568

F-68008 COLMAR Cedex

Tél./Fax. : +33 3 89 20 23 64/84

Mél : benoit.hilt <at> uha.fr/ <at> calixo.net

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

headers

Subinoy Das | 16 May 2007 14:30

Query about BSR election

Hi,

I have some confusion about BSR election in draft "draft-ietf-pim-sm-bsr-09".

In Section 3.2 page 17 it says

"When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv
messages, waiting a small randomized period C_RP_Adv_Backoff before
sending each message."

But how C-RPs comes to know that BSR election is done and now it can prepare to send three C-RP-Adv messages?

Please reply me if anyone knows the answer.

Thanks and Regards,

Subinoy

Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.

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

headers

Subinoy Das | 16 May 2007 14:45

Query about RP-set construction at BSR

Hi,

I have one confusion about RP-set construction at BSR in draft "draft-ietf-pim-sm-bsr-09".

In Section 3.3 page 19 it says

"The BSR constructs the RP-Set from the C-RP-Set. It may apply a local
policy to limit the number of Candidate-RPs included in the RP-Set."

But what is the method to select RPs from the C-RP-set?

Please reply me if anyone knows the answer.

Thanks and Regards,

Subinoy

Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.

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

headers

sumanta seal | 16 May 2007 15:50

Re: Query about BSR election

Hi Subinoy,

The elected BSR's BSM informs all other routers in the domain that it is the elected BSR.

A C-RP can fall into two category -
1. Candidate-BSR
2. Non-Candidate-BSR

Now, in the first case, where the C-RP is configured as a Candidate-BSR, the elected BSR is identified following the Candidate-BSR State machine (specified section 3.1.1 in draft "draft-ietf-pim-sm-bsr-09"). The C-RP functionality of the Candidate-BSR router use this information to determine the elected BSR. Whenever a elected BSR changes, each Candidate-BSR router knows this from Candidate-BSR State machine, hence the C-RP functionality also get informed about the change and sends one-to-three C-RP-Adv messages.

In the second case, on receiving a BSM (preferred or non-preferre d), a router always moves to Accept Preferred state in Per-Scope-Zone state machine for Non-Candidate BSR (section 3.1.2 in draft "draft-ietf-pim-sm-bsr-09"), irrespective of whether it is in NoInfo or Accept Any state. Since in Accept Preferred state, the router knows the identity of the elected BSR, hence the C-RP functionality. The BSR change event is also get informed by the Per-Scope-Zone state machine and on such event the C-RP sends one-to three C-RP-Adv messages.

Rgds,
Sumanta

Subinoy Das <subinoy_das_82 <at> yahoo.com> wrote:

Hi,

I have some confusion about BSR election in draft "draft-ietf-pim-sm-bsr-09".

In Section 3.2 page 17 it says

"When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv
messages, waiting a small randomized period C_RP_Adv_Backoff before
sending each message."

But how C-RPs comes to know that BSR election is done and now it can prepare to send three C-RP-Adv messages?

Please reply me if anyone knows the answer.

Thanks and Regards,

Subinoy

Be a better Globetrotter. Get better tra vel answers from someone who knows.
Yahoo! Answers - Check it out. _______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Thanks & Regards,
**************************************************
Sumanta Seal
Salt Lake City, Kolkata
West Bengal
**************************************************

Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Here's a solution!

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

headers

sumanta seal | 16 May 2007 16:14

Re: Query about RP-set construction at BSR

Hi,

The BSR constructs the RP-set from the received C-RP-set depending on the values of the RP Priority and RP Holdtime. The BSR chooses the RP from a set of C-RP for a specific multicast group based on the lower value of the RP priority (i.e., the RP having lowest value of RP priority among the C-RP-set for a specific multicast group, is chosen as the RP for that group).
If the holdtime for a RP in the C-RP-Adv message is zero, the RP is removed from the RP-set, if it is there.
Also when the CGET for a RP in the elected RP-set is expired, the RP is removed from the set.

Rgds,
Sumanta

Subinoy Das <subinoy_das_82 <at> yahoo.com> wrote:

Hi,

I have one confusion about RP-set construction at BSR in draft "draft-ietf-pim-sm-bsr-09".

In Section 3.3 page 19 it says

"The BSR constructs the RP-Set from the C-RP-Set. It may apply a local
policy to limit the number of Candidate-RPs included in the RP-Set."

But what is the method to select RPs from the C-RP-set?

Please reply me if anyone knows the answer.

Thanks and Regards,

Subinoy

Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games._______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Thanks & Regards,
**************************************************
Sumanta Seal
Salt Lake City, Kolkata
West Bengal
************************** ************************

Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Here's a solution!

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

34	May 2013
34	April 2013
13	March 2013
16	February 2013
17	January 2013
6	December 2012
9	November 2012
13	October 2012
11	September 2012
6	August 2012
11	July 2012
8	June 2012
19	May 2012
24	April 2012
41	March 2012
12	February 2012
12	January 2012
1	December 2011
13	November 2011
32	October 2011
38	September 2011
18	August 2011
15	July 2011
30	June 2011
25	May 2011
36	April 2011
22	March 2011
107	February 2011
17	January 2011
24	December 2010
14	November 2010
10	October 2010
3	September 2010
25	August 2010
11	July 2010
12	June 2010
29	May 2010
24	April 2010
12	March 2010
6	February 2010
2	January 2010
7	December 2009
13	November 2009
16	October 2009
2	September 2009
20	August 2009
22	July 2009
11	June 2009
1	May 2009
5	April 2009
14	March 2009
6	February 2009
7	January 2009
15	December 2008
4	November 2008
15	October 2008
21	September 2008
17	August 2008
41	July 2008
22	June 2008
23	May 2008
11	April 2008
4	March 2008
17	February 2008
30	January 2008
3	December 2007
13	November 2007
15	October 2007
52	September 2007
17	August 2007
17	July 2007
22	June 2007
23	May 2007
8	April 2007
8	March 2007
15	February 2007
24	January 2007
7	December 2006
20	November 2006
35	October 2006
3	September 2006
24	August 2006
34	July 2006
22	June 2006
20	May 2006
74	April 2006
33	March 2006
39	February 2006
38	January 2006
15	December 2005
122	November 2005
65	October 2005
5	September 2005
33	August 2005
9	July 2005
3	June 2005
42	May 2005
40	April 2005
27	March 2005
11	February 2005
28	January 2005
7	December 2004
44	November 2004
52	October 2004
40	September 2004
11	August 2004
20	July 2004
15	June 2004
32	May 2004
28	April 2004
39	March 2004
19	February 2004
21	January 2004
4	December 2003
18	November 2003
40	October 2003
25	September 2003
8	August 2003
16	July 2003
14	June 2003
58	May 2003
19	April 2003
76	March 2003
30	February 2003
7	January 2003
28	December 2002
8	November 2002
25	October 2002
33	September 2002
18	August 2002
33	July 2002
26	June 2002
41	May 2002
27	April 2002
1	October 2001

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31