Subject: [pim] PIM Group Set Source List Rules

From: "Singh, Gurpreet" <[email-masked]>
Date: Mon, 6 Oct 2003 08:03:32 -1000

Hi

I have a question regarding the group source list rules for PIM Join/Prune
messages defined in the draft draft-ietf-pim-sm-v2-new-07.txt  Section
4.10.5.1 

The table listing the cobination of Join and Prunes in a single Join/Prune
message has "no" and "?"

no   Combination is not allowed by the protocol and MUST NOT be
     generated by a router.

?    Combination not expected by the protocol, but well-defined. A
     router MAY accept it but SHOULD NOT generate it.

Is it correct to infer from this that for combinations marked as "no" router
should not accept the PIM-SM Join/Prune message and just drop the message if
it receives a PIM-SM Join/Prune message with the "no" combination ? Or is it
that the behaviour for accepting or droping this kind of packet is not
defined in the spec and is left to the deiscretion of the implementation.
But if that is the case then "no" and "?" would be similar in behaviour.

Thanks

Gurpreet

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

---

From: John Zwiebel <[email-masked]>
Date: Mon, 6 Oct 2003 12:40:52 -0700

> But if that is the case then "no" and "?" would be similar in 

The "no" combinations are "obvious" contradictions.  For example,
a (*,G) join and a (*,G) prune in the same message represents a 
"paranoid"
behavior on the part of the sender who can't seem to make up his mind
about what he wants.

It took a few years to recognize that PIM join/prune messages have to
be processed "atomically" (in the same sense that SNMP has to be
processed atomically).  For example, a (*,G) join message has to
"look ahead" in the j/p message to ensure there isn't a (S,G,R) prune
further on or the router will incorrectly add an OIF and may then
incorrectly forward data leading to all sorts of problems (possibly
an assert exchange for instance) as time goes on.

(FWIW, I found that 1pps was enough to discover the forwarding problem.
and you may want to include a data stream in your test instrument to
specifically look for that problem.  Also, FWIW, I can not imagine
why no one complained about the problem during the time I was ignoring
it because I had "more important" things to worry about.  ;-)

The spec does not say that these contradictory messages should be 
dropped.
It -might- be a good idea to do so, but the reality is that looking
ahead through an entire join/prune message to ensure it doesn't contain
any such contradictions could become rather process intensive, 
especially
as the number of groups starts to get larger and larger.  One -might-
then suggest that all j/p messages received from the same neighbor
within x amount of time have to be examined to ensure there are no
contradictions.  (I'm expanding beyond the scope of your question, to
illustrate the 'never-ending' nature of what might be possible.)

So, from a test instrument perspective, you want to figure out a
way of triggering such a contradiction so you can test it (I think
it may be difficult to do, I don't have a clue) but you certainly
-cannot- say that if your test instrument sends such a message and
the router processes it that the router has failed the test.

WRT the "?" items.  These represent items that are "complementary"
and "redundant".  For example, a (*,G) prune with a (S,G,R) prune
-should- accomplish the same thing WRT a (S,G,R) entry (ie remove
the OIF from the Olist.  There's little reason to include the (S,G,R)
prune.

Another example, a (*,G) prune with a (S,G,R) join, is a 'unique'
situation.  One -might- be able to make a persuasive argument that
such a message has utility in some situations.  (Especially when
the use of IGMPv3 is contemplated).  Yet within the "standard"
model under which ASM works over the past 10 years, such a message
is "senseless".  But, by allowing the loophole in the RFC, perhaps
the ASM model can be expanded in the future to meet needs currently
not anticipated.  Such a need would probably be recognized by a
given vendor and so the definition of "?" in the spec allows that
flexibility while still emphasizing that it isn't a "good idea".

 From a test instrument perspective, it is important (IMHO) that
you generate "?" type messages and ensure that the router correctly
processes the message.  If the router fails, it should be flagged as
a "conditional failure" which means that the strictest interpretation
of the ASM model would suggest that such a failure won't cause
any interoperability problems so "who cares".  And unless you
subscribe to the potential changes I've outlined above, the answer
would be "no one".  :-)

I hope this is helpful.
z