Subject: RE: Assert on outgoing interface

From: vishwas <[email-masked]>
Date: Tue, 10 Nov 98 21:12:00 PST

In message <[email-masked]>you write:
>A new draft 01 is released, it would be nice to have another writeup
>giving the difference between the previous version and this.

I did a diff; there were several minor wording changes and a couple of
extra sentences added.

1. Change "flooding" to "broadcasting" in 4th paragraph of section 4,   
even
though for PIM-DM, "flooding" is the more correct term.

[vishwas]
True.
2. Slight wording change in the beginning of section 5.
[vishwas]
:-(
3. Slight wording change in 2nd para of section 5.1
[vishwas]
:-)
4. Clarify wording about Asserts in 3rd para of 5.1 (don't say "prunes")
[vishwas]
:-)
5. Strengthen wording about not sending prunes in response to each packet
you get on a negative cache entry (1st para of 5.2.1).

[vishwas]
must ->  MUST
6. Minor wording change when talking about filling in 0.0.0.0 as upstream
router.

7. Added rate-limiting prunes when receiving prunes on an outgoing P2P
interface.

[vishwas]
But is the rate limiting really required for prunes or asserts in   
general..?
esp. for prunes when HOLDTIME in the join/prune message will cause the   
upstream to block data and so prunes may not be sent that regularly. Same   
thing applys to asserts too I suppose..!!!
8. Minor wording change with Assert timer.
[vishwas]  ?????
9. A little more info about the graft packet format.
[vishwas]
:-))

I have a slight problem with #1.  I think I have a real problem
with #7.  Pruning off redundant P2P links fits so nicely into the
job of Asserts, and kind of poorly into the job of Prunes.

  Bill

[vishwas]

section 5, first pyra, last sentence,     or can be replaced by,

1) and/or .....host members for group G.
2) Also in the begining of this pyra, it should be made clear that the   
forwarding entry is created only on recept of multicast data, so the   
sentence "If a receiving router does not already have a forwarding entry,   
it creates it for the  source and group G." may need to be re-phrased.   
And it should also be mention in this pyra that, if mcast data fails RPF   
lookup then, the packet should be dropped.

3) I find that many drafts are not making a proper use of section 2   
Terminology, though they include it.

I suppose may and must be in CAPITALS to stress it.
Authors pl. give a thought to this in the next version of  this draft.

4) Section 5.4 DR Election
    I think its time to mention "The implementations confirming to this   
version of the draft should use IGMPv2"

5) Section 5.5 How to assign a preference value in asserts, for sources   
which are directly connected...?
    I read some where saying it should be zero. Why this deviation..?

6) I feel it is un-necessary to send an assert AGAIN by an assert winner,   
just to tell other routers who WON, when they allready know they are the   
LOOSERS. Can this sentence be eliminated from section 5.5.....?

7) A small typo in section 5.5 last sentence,  ... 3   whent he --->   
  when the
Comments please.!!!

8) Another typo in section 6.7
      .... The source address SHOULD be included in THE ....

I better do a spell check now... use WINDOZE...

9) Typo section 1    "employs"

10) Typo section 5.2.1 8th pyra 2nd sentence,
      WINDOZE says   "occurrence"

11) Typo section 5.4 2nd pyra
     "periodically"

COMMENTS PLEASE....

Regards
vishu

---

From: Liming Wei <[email-masked]>
Date: Tue, 10 Nov 1998 23:00:49 -0800 (PST)

> From: vishwas <[email-masked]>
> 

This is to serve as a guideline to implementors, to deal with abnormal
situations when an implementation errors occur (not necessarily in the
local host). In general, we don't even need to mention it for
completeness.

> 1) and/or .....host members for group G.

Don't know what you are referring to.

> lookup then, the packet should be dropped.

IMO, the existing text is pretty clear by itself.

> Authors pl. give a thought to this in the next version of  this draft.

 Noted.

> version of the draft should use IGMPv2"

I think this is not necessary, since it is not upto a router which
IGMP version it needs to choose. It takes just one host to run
IGMPv1, to bring the entire segment to IGMPv1. And we MUST support
IGMPv1 applications (sometimes when people can not upgrade, it is
because the old application is the most important business application).

>     I read some where saying it should be zero. Why this deviation..?

It takes the value from configured unicast routing protocol precedence,
which is administratively changeable in normal implementations.

> LOOSERS. Can this sentence be eliminated from section 5.5.....?

Can't do that. Others need to know who won.

> 7) A small typo in section 5.5 last sentence,  ... 3   whent he --->   

Fixed.

> I better do a spell check now... use WINDOZE...

Fixed.  (Yeh, there have been plenty of windows on my screen,
obviously I spell checked the wrong one.)

> 9) Typo section 1    "employs"

Fixed.

>       WINDOZE says   "occurrence"

Fixed.

> 11) Typo section 5.4 2nd pyra

Fixed.

> COMMENTS PLEASE....

 Thanks.

-Liming

---

From: Bill Fenner <[email-masked]>
Date: Wed, 11 Nov 1998 07:49:08 PST

>Can't do that. Others need to know who won.

I think Vishu is right.  If this router has sent an Assert already, then
it doesn't need to send it again -- it only needs to send the "I won"
Assert message if it hasn't sent an Assert recently.

i.e.
1. A sends Assert saying [1,20]
2. B sends Assert saying [1,15]
3. A receives B's Assert and shuts up
4. B receives A's Assert and decides that it has won.  B sends another Assert
  saying [1,15].
What is the value of the 2nd Assert message from B?

  Bill