Subject: [pim] Comments on PIM-DM draft 5

From: PIM Guru <[email-masked]>
Date: Wed, 29 Sep 2004 14:18:26 -0700 (PDT)

Hi,

1.) Sec 4.5.1 (Forwarding of SR) mentions that
Prune-Ind Bit be Set (to 1) iff forwarding interface I
is in prunes (S,G) (DS State == PRUNED). However, Sec
4.5.2.2 (Transitions from Originator State) mentions
that Prune-Ind Bit be Set (to 1) iff forwarding
interface I is in NoInfo state (DS State == NoInfo).
Is this inconsistency between SR Originator and SR
Forwarder, intentional and if so why?

2.) Sec 4.5.2.2 (Transitions from Originator State)
states:

"The router ***SHOULD*** increase its recorded TTL to
match the TTL of the packet..."

The next para states:

"If the TTL ..... are being recorded, then ... .
Otherwise, the TTL is set to the configured SR TTL".

IMO, the "SHOULD" must be dropped and the recording of
TTL value from the data packets made explicitly
optional. Moreover, recording TTL value by peeking
into MCast forwarder for ***every data frame*** is a
very expensive brain dead idea. On conventional Mcast
forwarders like those on Linux and Netbsd, this would
make PIM-DM the most CPU consuming task! (atleast on
routers directly connected to the Source)

Infact, IMO, this TTL field in the SR is in itself
redundant since a router would not have created an
(S,G) State if it did not receive any datagram for it.
So it is highly point-less to expect a router to
forward an SR for which it does not have an (S,G)
entry. If everyone agrees, we should probably drop
this TTL field in SR or obsolete it. And it may be
prudent to make a mention in the draft (say, under Sec
4.2 Data Packet Forwarding Rules:) that "PIM-DM
routers will discard data frames with TTL of 1". This
change would be much better that sampling TTL values
from every data frame and may require implementations
to sample the TTL field of the data-frame for just the
first data-frame which results in a NOCACHE/WRONGVIF
message.

-Guru

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: "Nicholas, Jonathan" <[email-masked]>
Date: Thu, 30 Sep 2004 11:38:27 -0400

Hello,

The Prune Ind Bit is a small oversight.  The bit is to be set to 0 in the Prune Pending and No Info states.  It is to be set to 1 in the Pruned state.  4.5.2.2 is mostly correct in that it specifies the bit is to be set to 0 when in the No Info state.  It should be corrected to include the Prune Pending state as well.

As to the SR TTL, it is necessary, because a router need not retain state information for multicast messages it is forwarding.  That is, forwarding is the default state with no requirements concerning how long the state persists since if the state is dropped, it can always be reinstantiated.  While I believe routers will retain a forwarding state for some time, it is not necessary (from a specification point of view) to specify how long that is.

Having said that, sampling the TTL is recommended, but not mandatory.  If your implementation has concerns about the CPU overhead, it can sample at a lower rate, or once for the first packet, or not at all.  The intent is to be able to maintain state for everyone who might be receiving the messages and desiring to maintain state.

Perhaps a statement should be added to clarify that a router may sample TTL at a lower rate.

Jonathan Nicholas
Network Systems Engineer
ITT Aerospace/Communications Division

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On

> Behalf Of PIM
> Guru
> Sent: Wednesday, September 29, 2004 5:18 PM
> To: [email-masked]
> Subject: [pim] Comments on PIM-DM draft 5
>

> -Guru

************************************
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Industries, Inc. The recipient should check this e-mail and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this e-mail.
************************************