Subject: Re: [pim] PIM-SM v2 deployment issues - 1 minute latency?

From: "Sundeep Singatwaria" <[email-masked]>
Date: Tue, 6 Nov 2001 10:17:05 -0800

-----Original Message-----
From: John Zwiebel <[email-masked]>
To: Shekhar, Ravi <[email-masked]>
Cc: Philip Ho <[email-masked]>; PIM mail <[email-masked]>
Date: Friday, November 02, 2001 2:23 PM
Subject: Re: [pim] PIM-SM v2 deployment issues - 1 minute latency?

>
>
>>
>> Hi John,
>>   In case the RP has sent a register-stop to the sender-DR, the protocol
>>   itself doesnt provide any mechanism to cancel that register-stop sent
>>   earlier, in which case it could take as much as 60 seconds before RP
>> starts
>>   getting register-messages again.
>
>When the RP gets the first register it is suppose to create and maintain
>(S,G) state with a NULL olist.
>

An implementation may decide not to create S,G state at RP till the OIF list
is NULL. Reason being if there are lot of sources with no receivers in the
network (DOS attack) then the RP switch needs to have good amount to memory
to preserve all the S,G entries.  Downside of this is the join latency can
be 60 s.

To avoid join latency - the only way out is to maintain S,G entries.

Sundeep

>>
>>   What you are suggesting requires that RP triggers a switch to the
shortest
>>
>>   path <S, G> on its own. But that isnt something mandated by the old
PIM-SM
>>
>>   draft (I havent read the new one to comment on it). Am I missing
>> something?
>>
>
>Any router that has (S,G) state that receives a (*,G) join on an
>interface that is not in the (S,G) olist should add that interface
>to the (S,G) olist.  (It is an inherited olist, which may be important
>in some implementations but which is not yet recognized by all yet,
>and may not be -- remember Cisco's X-flag).
>
>This would change the upstream interface to "JOIN-DESIRED" == TRUE.
>meaning, _any_ router, not just the RP, should trigger a join toward
>the source.
>
>FWIW, the RP can be thought of as a "virtual receiver".  The line
>between the source and the RP (called the X-line for want of a better
>term) is a branch of the shortest path tree.  Any time the RP has
>a (*,G) with a non-NULL olist it is suppose to be sending JOINs toward
>the source (in general).  So, yes the RP is suppose to join to the
>shortest-path on its own.
>
>I don't want to repeat what is suppose to happen because of (S,G,R)
>prunes here because that is, in some ways, implementation dependent.
>It also gets complicated by the 'inherited/immediate' olist questions.
>
>So, yes the RP is always suppose to be able to join the SPT on its own.
>
>FWIW, the important part of the PIM register packet isn't that it
>includes the encapsulated first data packet.  Its that this message
>informs the RP of a source that is sending so the RP can join toward
>the source.  The data is encapsulated so receivers have the _potential_
>of getting the first packet.  In practice, this has proven to be
>extremely problematic.  What good is it to receive the first packet but
>lose 2-n as the last hop router switches to the SPT?  (This is a
>implementation problem not necessarily a PIM protocol problem, and
>probably a point I shouldn't have brought up in this thread since its
>orthogonal.).
>
>z

---

From: John Zwiebel <[email-masked]>
Date: Tue, 06 Nov 2001 10:29:10 -0800

> To avoid join latency - the only way out is to maintain S,G entries.

Perhaps this should be configurable.

z