headers
Prashant Jhingran | 2 Jan 2004 05:52
Favicon

RE: [Internet-Drafts <at> ietf.org: I-D ACTION:draft-ietf-pim-anycast-rp-00.txt]

Hi Dino,

I shall try to explain my second point, kindly refer to the diagram on page
2 of the draft.

Consider a case where SDR for a particular source S1 (e.g. S1, G) is also
the anycast RP for the same group G (e.g. RP1 is the RP for group G besides
being SDR for S1, G) or in simple words source S1 (S1, G) and RP for the
group G are directly attached.

In this case since there won't be any Register phase between source (S1) and
the RP (RP1) therefore the RP/SDR (i.e. RP1) has to "explicitly form" a
Register message with the required parameters as specified in the draft and
then forward the same to all the configured anycast RP's (viz. RP2 and RP3).

However in normal circumstances the following holds good:
"RP1 is configured with RP2 and RP3's IP address. It will forward the
Register message from S1's DR to both of them. RP1 will include it's own IP
address as the source address for the PIM Register message."

I would suggest you to include this particular scenario in the draft.

Let me know in case of any ambiguity.

Kind regards,
Prashant Jhingran

-----Original Message-----
From: pim-admin <at> ietf.org [mailto:pim-admin <at> ietf.org]On Behalf Of Dino
Farinacci
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dino Farinacci | 3 Jan 2004 18:37

Re: [Internet-Drafts <at> ietf.org: I-D ACTION:draft-ietf-pim-anycast-rp-00.txt]

>> In this case since there won't be any Register phase between source (S1) and
>> the RP (RP1) therefore the RP/SDR (i.e. RP1) has to "explicitly form" a
>> Register message with the required parameters as specified in the draft and
>> then forward the same to all the configured anycast RP's (viz. RP2 and RP3).

    This is explained in various PIM drafts. Either provision in the 
    implementation must be made to deal with this case, or you generalize
    the mechanism to internally build a Register message and send it to
    yourself (so reecived Register processing is the same for any directly
    connected source -- even when it is yourself).

>> I would suggest you to include this particular scenario in the draft.

    However, this scenario is "when to send Registers" as a functioning DR.
    The PIM draft really has the details to this. The Anycast-PIM draft 
    specifies when and how Registers are *forwarded*.

>> Let me know in case of any ambiguity.

    It is clear now. Thanks.

Dino
Permalink | Reply | 0 comments |
headers
James Lingard | 23 Jan 2004 16:39
Favicon

Error in PIM-SM forwarding rules

Hi,

I am new to PIM and have recently been studying the PIM-SM draft.  I believe
that there may be an error in the forwarding rules in the current draft
(draft-ietf-pim-sm-v2-new-08.txt, Section 4.2), which could cause a router
with only (*,G) forwarding state to incorrectly stop forwarding traffic from
a particular source.

The problem is with the clause

  'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )'

Why is the second test 'UpstreamJPState(S,G) == Joined' and not 'SPTbit(S,G)
== TRUE'?  It appears that as they stand the rules would cause a router with
only (*,G) forwarding state to stop forwarding traffic from S if SPTbit(S,G)
were set to TRUE.  This may happen in the following scenario.

Suppose that all of the following are true.

- RPF_interface(RP(G)) == RPF_interface(S)
- JoinDesired(*,G) == TRUE
- JoinDesired(S,G) == FALSE
- (S,G) Assert state-machine is in NoInfo state

If now a Preferred (S,G) Assert is received on RPF_interface(RP(G)), the
(S,G) Assert state-machine will switch to the "I Am Assert Loser" state,
performing Actions A6 which cause SPTbit(S,G) to be set to TRUE.  Once this
has happened, any (S,G) traffic received on RPF_interface(RP(G)) will not be
forwarded, because neither
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Zwiebel | 23 Jan 2004 18:00

Re: Error in PIM-SM forwarding rules


On Jan 23, 2004, at 7:39 AM, James Lingard wrote:

>
> The problem is with the clause
>
>   'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )'
>
> Why is the second test 'UpstreamJPState(S,G) == Joined' and not 
> 'SPTbit(S,G)
> == TRUE'?  It appears that as they stand the rules would cause a 
> router with
> only (*,G) forwarding state to stop forwarding traffic from S if 
> SPTbit(S,G)
> were set to TRUE.

If a router has only (*,G) state then this line would be false and you'd
fall through to the next elseif which defines how to forward on the
shared tree.

You can't set the SPT bit until after you've received traffic on the
(S,G) because that is when you can decide to start sending the (S,G,R)
prunes to stop that traffic from coming down the shared tree.
Permalink | Reply | 0 comments |
headers
James Lingard | 23 Jan 2004 18:12
Favicon

RE: Error in PIM-SM forwarding rules

Hi Mark,

Thanks for the quick response.  See comment below.

> -----Original Message-----
> From: Mark Handley [mailto:M.Handley <at> cs.ucl.ac.uk]
> Sent: 23 January 2004 16:20
> To: James Lingard
> Cc: 'pim <at> ietf.org'
> Subject: Re: [pim] Error in PIM-SM forwarding rules 
>
> >Suppose that all of the following are true.
> >
> >- RPF_interface(RP(G)) == RPF_interface(S)
> >- JoinDesired(*,G) == TRUE
> >- JoinDesired(S,G) == FALSE
> >- (S,G) Assert state-machine is in NoInfo state
> >
> >If now a Preferred (S,G) Assert is received on 
> >RPF_interface(RP(G)), the (S,G) Assert state-machine will switch 
> >to the "I Am Assert Loser" state, performing Actions A6 which 
> >cause SPTbit(S,G) to be set to TRUE.  Once this has happened,
> >any (S,G) traffic received on RPF_interface(RP(G)) will not be
> >forwarded, because neither...
> 
> The rules for transitioning from "NoInfo" to "I Am Assert 
> Loser" state are:
> 
>      Receive Preferred Assert with RPT bit clear AND
>           AssertTrackingDesired(S,G,I)==TRUE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 24 Jan 2004 12:36
Picon

New I-D on PIM-SM multicast routing security (fwd)

FYI,

There are already some suggestions for enhancements, maybe worth 
considering for the PIM-SM revisions.  And more in the works.

Initial feedback from the "protocol side" would be greatly
appreciated. :-)

---------- Forwarded message ----------
Date: Sat, 24 Jan 2004 13:34:15 +0200 (EET)
From: Pekka Savola <pekkas <at> netcore.fi>
To: mboned <at> lists.uoregon.edu
Cc: Lehtonen Rami <rami.lehtonen <at> teliasonera.com>, dmm <at> 1-4-5.net
Subject: New I-D on PIM-SM multicast routing security

Hello all,

When discussing the security properties of Embedded RP at the last
IETF, it was identified that it would be useful to analyze the
multicast routing security issues in general.

So, me, Rami Lehtonen and Dave Meyer got down to it.  Here's the 
result.  The main thing it lacks at the moment are concrete proposals 
on which kind of rate-limiting (etc.) mechanisms would be useful.   
We'd like to get feedback/discussion on that (and other comments are 
also very welcome).

http://www.ietf.org/internet-drafts/draft-savola-mboned-mroutesec-00.txt

Comments welcome.  Rami acts as the editor of the document.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Handley | 23 Jan 2004 17:20
Picon
Picon
Favicon

Re: Error in PIM-SM forwarding rules


>I am new to PIM and have recently been studying the PIM-SM draft.  I believe
>that there may be an error in the forwarding rules in the current draft
>(draft-ietf-pim-sm-v2-new-08.txt, Section 4.2), which could cause a router
>with only (*,G) forwarding state to incorrectly stop forwarding traffic from
>a particular source.
>
>The problem is with the clause
>
>  'if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined )'
>
>Why is the second test 'UpstreamJPState(S,G) == Joined' and not 'SPTbit(S,G)
>== TRUE'?  It appears that as they stand the rules would cause a router with
>only (*,G) forwarding state to stop forwarding traffic from S if SPTbit(S,G)
>were set to TRUE.  This may happen in the following scenario.
>
>Suppose that all of the following are true.
>
>- RPF_interface(RP(G)) == RPF_interface(S)
>- JoinDesired(*,G) == TRUE
>- JoinDesired(S,G) == FALSE
>- (S,G) Assert state-machine is in NoInfo state
>
>If now a Preferred (S,G) Assert is received on RPF_interface(RP(G)), the
>(S,G) Assert state-machine will switch to the "I Am Assert Loser" state,
>performing Actions A6 which cause SPTbit(S,G) to be set to TRUE.  Once this
>has happened, any (S,G) traffic received on RPF_interface(RP(G)) will not be
>forwarded, because neither...

The rules for transitioning from "NoInfo" to "I Am Assert Loser" state are:
(Continue reading)

Permalink | Reply | 1 comment |
headers
| 28 Jan 2004 02:16
Picon
Favicon

PIM BSM fragmentation


Hi all,

I would like to know why fragmentation support (read fragmentation tag) is required at PIM level when IP is
already doing it.

Thanks,
ARUT

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Permalink | Reply | 4 comments |
headers
John Zwiebel | 28 Jan 2004 02:25

Re: PIM BSM fragmentation


On Jan 27, 2004, at 5:16 PM, "" <aruts <at> excite.com> wrote:

>
> I would like to know why fragmentation support (read fragmentation 
> tag) is required at PIM level when IP is already doing it.
>

Because if IP does it, it may not include all the source for a given 
group within the same
packet.
Permalink | Reply | 3 comments |
headers
| 28 Jan 2004 08:54
Picon
Favicon

I


Hi,

IP actually does reassembly before it gives it to PIM and
PIM receives the complete packet intact.I have seen it work!

So, I don`t understand the need for a fragmentation flag!

Thanks,
Arut

 --- On Tue 01/27, Benjamin Black < ben <at> layer8.net > wrote:
From: Benjamin Black [mailto: ben <at> layer8.net]
To: jzwiebel <at> procket.com
     Cc: aruts <at> excite.com, pim <at> ietf.org
Date: Tue, 27 Jan 2004 19:54:05 -0800
Subject: Re: [pim] PIM BSM fragmentation

put a slightly different way:<br><br>PIM can generate a message larger than the maximum size for a single
IP <br>packet, so it must be able to reassemble things when a single PIM <br>message is fragmented over
multiple IP packets.<br><br><br>ben<br><br>On Jan 27, 2004, at 5:25 PM, John Zwiebel
wrote:<br><br>><br>> On Jan 27, 2004, at 5:16 PM, "" <aruts <at> excite.com> wrote:<br>><br>>><br>>> I
would like to know why fragmentation support (read fragmentation <br>>> tag) is required at PIM level
when IP is already doing it.<br>>><br>><br>> Because if IP does it, it may not include all the source for a
given <br>> group within the same<br>> packet.<br>><br>><br>>
_______________________________________________<br>> pim mailing list<br>> pim <at> ietf.org<br>> https://www1.ietf.org/mailman/listinfo/pim<br>><br>><br><br>

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
(Continue reading)

Permalink | Reply | 8 comments |

Gmane